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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Digital Enhanced Cordless 
Telecommunications (DECT). 

The present document is based on EN 300 175, parts 1 [1] to 8 [8], EN 300 444 [14] and EN 301 649 [15]. General 
attachment requirements and speech attachment requirements are based on EN 301 406 [11] (replacing TBR 006 [i.2]) 
and EN 300 176-2 [10] (previously covered by TBR 010 [i.3]). Further details of the DECT system may be found in 
TRIOI 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [12]. 

The information in the present document is believed to be correct at the time of publication. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 4 of a multi-part deliverable covering the New Generation DECT as identified below: 

Part 1: "Wideband speech"; 

Part 2: "Support of transparent IP packet data" ; 

Part 3: "Extended wideband speech services"; 

Part 4: "Light Data Services; Software Update Over The Air (SUOTA), content downloading and HTTP 
based appUcations". 
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1 Scope 

The present document specifies a set of functionalities of the New Generation DECT. 

The functionaHties defined in this profile are based on DECT base standard, EN 300 175, parts 1 [1] to 8 [8], DECT 
Generic Access Profile (GAP), EN 300 444 [14], and DECT Packet Radio Service (DPRS), EN 301 649 [15]. 

The New Generation DECT provides the following basic new functionaUties: 

• wideband voice service; 

• packet-mode data service supporting Internet Protocol with efficient spectrum usage and high data rates. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT data applications, with the features of the present document being a common fall-back option 
available in all compliant to this profile equipment. 

DECT does not standardize Internet Application protocols or other high layer data protocols, which are in the scope of 
other standardization organizations. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 
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[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DLC) layer". 

[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 6: Identities and addressing". 

[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 175-8: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 8: Speech and audio coding and transmission". 

[9] ETSI EN 300 176-1 : "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 1: Radio". 

[10] ETSI EN 300 176-2: "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 2: Audio and speech". 

[11] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 

Digital Enhanced Cordless Telecommunications (DECT) covering the essential requirements 
under article 3.2 of the R&TTE Directive; Generic radio". 

[12] ISO/IEC 9646-6: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 6: Protocol profile test specification". 

[13] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[14] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[15] ETSI EN 301 649: "Digital Enhanced Cordless Telecommunications (DECT); DECT Packet 

Radio Service (DPRS)". 

[16] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech ". 

[17] ETSI TS 102 527-3: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 3: Extended Wideband Speech Services". 

[18] Void. 

[19] IETF RFC 791 (1981): "Internet Protocol" (STD 51). 

[20] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 

[21] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

[22] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[23] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax" (STD 66). 

[24] IETF RFC 2817: "Upgrading to TLS within HTTP/1.1". 

[25] IETF RFC 1034: "Domain Names - Concepts and Facilities" (STD 13). 

[26] IETF RFC 1035: "Domain Names - Implementation and Specification" (STD 13). 

[27] XHTMLTM 1.1- Module-based XHTML - World Wide Web Consortium Recommendation 

31 May 2001. 

NOTE: http://www.w3.org/TR/2001/REC-xhtmlll-20010531/ . 
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2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3] ETSI TBR 010: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements: Telephony applications". 

[i.4] ETSI TS 102 527-2: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 2: Support of transparent IP packet data". 

[i.5] The Broadband Forum's (formerly DSL-Forum) Technical Report 069 (TR-069): "Technical 

Reports for a Customer Premises Equipment (CPE) WAN Management Protocol". 

[i.6] Web pages of the Unicode Consortium. 

NOTE: http:// www. Unicode, org/ . 

[i.7] IETF RFC 3629 (2003): "UTF-8, a transformation format of ISO 10646". 

[i.8] IEEE 802.3: "IEEE Standard for Information technology - Specific requirements - Part 3: Carrier 

Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer 
Specifications" (also known as ISO/IEC 8802-3). 

[i.9] IEEE 802.5: "IEEE Standard for Information technology - Telecommunications and information 

exchange between systems - Local and metropolitan area networks - Specific requirements - 
Part 5: Token Ring Access Method and Physical Layer Specification" (also known as 
ISO/IEC 8802-5). 

[i.lO] IETF RFC 1661: "The Point-to-Point Protocol (PPP)". 

[i.l 1] ISO/IEC 8859-1: "Information technology — 8-bit single-byte coded graphic character sets — 

Part 1: Latin alphabet No. 1". 

[i.l2] ISO/IEC 8859-2: "Information technology — 8-bit single-byte coded graphic character sets — 

Part 2: Latin alphabet No. 2". 

[i.l3] ISO/IEC 8859-15: "Information technology — 8-bit single-byte coded graphic character sets — 

Part 15: Latin alphabet No. 9". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 301 649 [15] and the following apply: 

distributed application: application available to the user on a DECT handset, for which part of the code (behaviour) 
and/or data is located on the handset (local tier) and part of it is located in the network (remote tier), and more 
specifically on one or more HTTP servers hosted by-or on behalf of-the FP's vendor 

downloading server: See Software upgrade downloading server. 

Light Data Services (LDS): basic DECT data services with limited data rate and simplified implementation 

Management Server (MS): See Software upgrade management server. 
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software package: set of files sharing the same version identifier, and needed by the PP for instalHng or upgrading an 
appHcation or a firmware 

NOTE: The software package is often simply referred to as the "software". 

software upgrade Downloading Server (DS): site of a PP vendor, or operated on behalf of a PP vendor, from where 
the software image releases can be downloaded 

software upgrade Management Server (MS): site of a PP vendor, or operated on behalf of a PP vendor, where 
information about new software image releases for handsets, and their locations (on the downloading server) can be 
found 

Software Upgrade Over The Air (SUOTA): capability to upgrade the Software or the Firmware in the PP by means 
of downloading it from the FP via the DECT air interface 

software version identifier: parameter that identifies a software package, including the software package version 

NOTE: From PP to FP, this parameter identifies the currently installed software package. From FP to PP it 
identifies the software package to be installed as a result of the upgrade (and is shared by all the files 
needed for the upgrade). Details and examples are provided in clause 7.5.5.2.1. 

3.2 Symbols 

For the purposes of the present document, the symbols given in EN 301 649 [15] and the following apply: 

C For conditional to support (process mandatory) 

I For irrelevant or out-of-scope (provision optional, process optional), not subject for testing 

M For mandatory to support (provision mandatory, process mandatory) 

n Current requested file number (value of the "fileNumber" parameter in the current "Handset 

Version indication" command). 
N/A For not-applicable (in the given context the specification makes it impossible to use this 

capability) 
N^ Number of files to be downloaded for a given Software upgrade (1 < Nf < 15). 

O For optional to support (provision optional, process mandatory) 

O.x Option comprising number of items 

X Excluded, not allowed 

The symbols defined in this clause are applied for procedures, features, and services in the present document if not 
explicitly otherwise stated. The interpretation of status columns in all tables is as follows: 

• Provision mandatory, process mandatory means that the indicated feature service or procedure shall be 
implemented as described in the present document, and may be subject to testing. 

• Provision optional, process mandatory means that the indicated feature, service or procedure may be 
implemented, and if implemented, the feature, service or procedure shall be implemented as described in the 
present document, and may be subject to testing. 

NOTE: The used notation is based on the notation proposed in ISO/IEC 9646-7 [13]. 



£75/ 



12 



ETSI TS 102 527-4 VI. 1.1 (2009-10) 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in EN 301 649 [15] and the following apply: 

CLIP Calling Line Identification Presentation 

CLSS ConnectionLess Suplementary Service 

D-GMEP DPRS Generic Media Encapsulation Protocol 

DPRS DECT Packet Radio Service 

DS Download(ing) Server 

GAP Generic Access Profile 

GMCI Generic Media Context Identifier 

HTML HyperText Markup Language 

HTTP HyperText Transfer Protocol 

LDS LightData Services 

MS Management Server 

SSL Secure Sockets Layer 

SUOTA Software Upgrade Over The Air 

TLS Transport Layer Security 

URl Uniform Resource Identifier 

URL Uniform Resource Locator 

XHTML extensible HyperText Markup Language 

XML extensible Markup Language 



4 Description of services 

4.1 Services covered by the present document 



4.1.1 



Introduction 



The present document defines a set of what has been named "Light Data Services". Light Data Services are packet 
mode data services for specific applications, based on DPRS [15], and designed to be implementable using simplified 
operation modes. 

The following Light Data Services are defined by the present document: 

• Software Upgrade Over The Air (SUOTA); SUOTA may be automatic, user initiated, or possibly pushed from 
the management server. 

• Binary content download; this is used in SUOTA for the actual software download, and can also be used to 
define proprietary distributed applications to be used on handsets. 

• HTTP based applications; this is intended to allow the design of DECT specific applications based on a limited 
browsing functionality. 

Further Light Data Services may be created by further releases of the present document, or by other DECT 
specifications. 

4.1 .2 Application scenario 

The Light Data Services defined by the present document have been designed as a complement to voice service 
terminals. Therefore, the expected scenario is that PPs and FPs implementing the present specification, are also 
implementing one of the DECT voice services. The services defined by the present document have been optimized to be 
a natural complement of New Generation DECT; part 1: wideband speech [16], and New Generation DECT: part 3: 
extended wideband speech services [17]. However, it is also possible the use the Light Data Services in combination 
with plain GAP [14] terminals. 
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The application scenario assumes that there is a data connection at the DECT FP that allows the connectivity to external 
application servers that participate in the service from application point of view. Such data connectivity is typically via 
the Internet. However, other scenarios of connectivity may exist, including the case when the FP incorporates locally 
the network side application server. The network side implementation of the scenario is out of the scope of DECT 
standardization. However, the descriptions given in the present document will assume the most expected case of data 
connectivity via the Internet, and remote application servers located at any internet location. Other cases, as exotic 
connectivity or local implementation of the network side server are adaptation of the general scenario, without impact 
on the DECT air interface protocols. 

4.2 Light Data Services Protocol architecture 

The common characteristic of all Light Data Services defined by the present document is the use of the DPRS [15], 
generic media encapsulation interworking mode (DPRS [15], clause B.8). The generic media encapsulation is a DPRS 
facility that allows the direct transportation of multiple application protocols. In the case of the Light Data Services 
defined in the present document, the application protocol is HTTP (as defined by RFC 2616 [22]) supporting only the 
modes defined by DPRS [15], clause B.8. 

Another characteristic of the protocol architecture defined in the present document is that the application protocol is 
transported without the use of any transport layer protocol (TCP [21] or UDP [20]). This approach, that has been chosen 
in order to simplify implementations, relies on the request/response nature of the application protocol and requires some 
collaboration from it in order to perform the tasks normally done by the transport layer (TCP). 

The result of the approach is that PPs do not need to implement the TCP protocol. 

4.2.1 Data protocol reference configuration 

Figures 1 and 2 define the U-plane and C-plane protocol stacks used in the Light Data Services defined by the present 
document. 
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Figure 1 : Reference model of the U-plane protocol stack 
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4.3 



Figure 2: Reference model of the C-plane protocol stack 

Description of functionality and functional split between PT 
and FT 



The top level service provided to the Portable Part implementing the present document is a layer 7 application based on 
the ietf protocol HTTP [22]. Assuming the most usual scenario, as described in clause 4.1.5, the application level 
interaction happens between the DECT PP-that is therefore the end-point of the application protocol-and any host 
located at any Internet location, with TCP/IP connectivity towards the DECT system. 

The server located on the Internet-also called the network side server-is a regular "host" from Internet point of view, 
i.e. it is a host for IP [19], TCP [21] and the application layer. However, in the DECT system, the IP and TCP layers are 
terminated at the FP, while only the application layer travels to the PP. Therefore the DECT FP is the end-point for IP 
and TCP connections. 

4.3.1 Functionality of the DECT FP 

In addition to being the end-point of IP [19] and TCP [21] layers, the FP may be involved in a PP data session in 
different ways: 

• Simple forwarding of PP requests to the WAN (to DECT specific service), with possible adjustment of 
requests (Range header). 

• Forwarding of PP requests to the WAN (to a non DECT specific service), with adjustment of responses to the 
limited profiles used by the PP ("HTTP Common profile", "HTTP Browsing profile", "Light Browsing 
profile"). 

• Addition of a security service: creation of an SSL/TLS tunnel from FP to HTTP server. Refer to [24] for 
details. 

• Hosting of an HTTP server for local services. 

4.3.2 Functionality of the DECT PP 

The DECT PP acts as the end-point for the application protocol (HTTP). The PP is usually the "client" in a client/server 
relationship with the network host that is usually the "server". However this asymmetric relation is irrelevant from the 
DECT point of view, that would as well support the opposite client/server relationship if required. 

4.3.3 U-plane interworking and protocol architecture 

The U-plane protocol architecture (see figure I) reflects the principle of TCP and IP termination at FP side. The 
application protocol (HTTP in all cases covered by the present document) is transported over DPRS LUlO service using 
the generic encapsulation described in clause B.8 of EN 301 649 [15]. 
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The fact that the air interface transport is done without a transport layer, requires some cooperation from the application 
layer. In the case of HTTP, the message oriented structure of the protocol with a request/response operation mode in 
near all cases, makes this direct operation possible. The design of the application at both places should, however, take 
into account that it will be transported without a transport layer (TCP) over part of the data path. 

The DPRS U-plane transport (LUlO) is able to deliver the application packets in a reliable way and is able to carry 
information about the position of the application packet boundaries. In the event of impossibility of reliable 
transmission (for instance due to successive radio errors), the DPRS U-plane transport is able to indicate to application 
layer that the received application packet is not complete. 

4.3.4 Dynamic considerations on U-plane 

Due to the operation without transport layer, one of the factors that must be considered by the HTTP application design 
at both sides is using a correct value for the maximum size of the HTTP packets (messages). While the operation with 
TCP allows the transportation of variable size and virtually very large application packets, in the scenario covered by 
the present document, it is convenient to restrict the size of the packets to proper values, that makes the ratio "size of the 
application packet/size of the DECT DLC segment" not too large. The DECT DLC segment is the PDU of the LUlO, 
with a size of 64 bytes for 2-level modulation and long slot. 

For optimal operation, the value of this ratio should be dynamically adjusted depending on the radio conditions: for 
optimal radio link quality the size of application packets (and the ratio) may be increased. If the radio link quality 
decreases, and there are transmission errors and DLC retransmissions, the ratio should be reduced, by reducing the 
maximum size of the application packets. 

NOTE 1 : However, this capability of dynamically adjusting the application packet depending on radio conditions 
requires communication between the DECT Management Entity and the application layer, and is seen as 
an option for advanced implementations. 

A value of 12 kbytes (equivalent to 200 times the DECT PDU size) is considered a convenient value for the maximum 
application packet size in FT => PT direction, and this is the mandatory figure to be supported by all devices 
implementing the present document. For the PT => FT direction, the mandatory value to be supported by all 
implementations is 1,5 kbytes. 

The implementations may optionally support the use of larger application packet sizes. The supported maximum size at 
both sides (when different of the default values) shall be announced by means of the «Setup Capability» IE 
(see clause 12.22 of EN 301 649 [15]). Application packet sizes larger than the default values may only be used when 
supported by both peers. 

The "Range" header of HTTP/1.1 should be used for controlling the application packet size at application level. The 
value set in the Range header should be consistent with the values announced in «Setup capabilities» IE. 

When application packet sizes larger than the default values are supported, it is assumed that the implementation has the 
capability to adjust the real size of the packets according to radio conditions. 

NOTE 2: It means that the applications should not use always, by default, the maximum supported size. 

PPs should control the size of the own sent application packets, and also the requested value for downlink packets by 
means of the "Range" header in HTTP/1.1 requests. 

The exact value of the application packet size, and how it is related to the radio conditions is up to the implementer. 

NOTE 3: A value of 32 000 bytes is equivalent to approximately 5 seconds of transmission over a single bearer, 
long slot channel and optimal radio conditions. 

NOTE 4: The Maximum allowed value of the SDU size defined in IWU- Attributes (see EN 301 649 [15], 

clause B.2.1) should also be taken into account. The use of application packet sizes larger than the SDU 
size requires the use of the optional chopping facility (see EN 301 649 [15], clauses B.8.2 and 12.22 for 
indicator in IE <Setup Capability>). The maximum value in SDU size indicators (EN 301 649 [15], 
clause B.2.1) is 131 064 bytes. 
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4.3.5 C-plane interworking 

The DECT C-plane is used for different functions in the Light Data Services architecture. One of the most obvious is 
the DPRS virtual call setup and release. In most application cases, this is usually done by the PP side after request of the 
data application (see for instance the figure 3). On the FP side, the sending of HTTP requests through the set-up virtual 
call triggers the opening of one or several TCP connections with the distant Internet host, or hosts (since in some 
scenarios several hosts participate in the service). In some cases, the DECT C-plane is used to transport the routing 
information (URL) of this network side server (see clause 7.5.5.2.1). 

It is also possible to use the opposite scenario, where the DECT FP receives a TCP connection from a distant host, and 
this action triggers a FP initiated virtual call setup towards the PP. This scenario is, however, less usual and, because of 
it, the FP initiated virtual call is optional. 

4.4 Service and Performance Objectives 

In order to allow wide use of the present specification, and taking into account that in most cases it will be a 
complement of DECT voice services, only single bearer operation over long slot and DPRS Class 4 are defined as 
mandatory. There is however the option of introducing DPRS Class 3 or Class 2 operation, and, when combined with 
Class 2, multibearer and asymmetric bearers support. 

The service and performance objectives are shown in tables 1 and 2. 

Table 1 : Summary of service capabilities 



Service 


DPRS Class mode 




Class 4 


Class 3 


Class 2 


Point-to-point protected data transfer PP-FP with ARQ 


YES 


YES 


YES 


Point-to-point protected data transfer FP-PP witli ARQ 


YES 


YES 


YES 


Point-to-multi-point data transfer FP-PP 


- 


- 


- 


Point-to-point data transfer PP-PP 
(distributed communication) 


- 


- 


- 


Autlientication 


YES 


YES 


YES 


Encryption 


YES 


YES 


YES 


Connection oriented operation 


YES 


YES 


YES 


Virtual Call (VC) operation 


YES 


YES 


YES 


Intra-cell bearer handover 


YES 


YES 


YES 


Inter-cell bearer handover 


YES 


YES 


YES 


Inter-cell connection handover (for multicell systems) 


OPTIONAL 


OPTIONAL 


OPTIONAL 


Inter-cell external handover 


OPTIONAL 


OPTIONAL 


OPTIONAL 


Suspend /resume 


- 


OPTIONAL 


YES 


Multibearer connections 






YES 


Asymmetric connections 






YES 


Fast setup 






OPTIONAL 
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Table 2: Summary of Performance objectives 



Performance 


DPRS Class 1 




Class 3 or 4 


Class 2 


Maximum supported SDL) size (FT = > PT) 


> 1 2 224 octets 


> 12 224 octets 


IVIaximum supported SDL) size (PT = > FT) 


> 1 528 octets 


> 1 528 octets 


IVIandatory sustainable unidirectional or bidirectional throughput. 


64 kbit/s 


64 kbit/s 


Optional maximum sustainable unidirectional throughput (Class 2 
system), GFSK 2-level modulation. 


- 


844,8 kbit/s net 


Optional sustainable full bi-directional throughput (DPRS Class 2 
system), GFSK 2-level modulation 


- 


460,8 kbit/s net 


Maximum one-way delay 


Down to 50 ms 
configurable 


Down to 50 ms 
configurable 


Establishment of PT to FT physical connection (average) 


< 50 ms 


< 50 ms 


Establishment of FT to PT physical connection (average) 


< 50 ms 


< 50 ms 


Undetected bit error ratio 


< 10-10 


< 10-10 


Uncorrected bit error ratio (for air interface BER 10"^ and 
delay = 100 ms) 


< 10-7 


<io-7 



4.5 General application environments 

Figures 3 and 4 describe the general application scenario of the Light Data Services described in the present document. 
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Figure 3: General application scenario (applicable to all services) 
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Figure 4: Application scenario for Software upgrade over the air (SUOTA) 



Relevant requirements 



The requirements of EN 301 649 [15] relevant for Class 2, Class 3 or Class 4 equipment shall apply with the 
modifications stated in clauses 5 and 6 of the present document. 

The encapsulation of external data protocol shall be done as stated in EN 301 649 [15], clause B.8. 

In any case, the requirements of EN 300 176-1 [9] and any of the harmonized standard EN 301 406 [11] shall apply as 
well. 



5.1 



Service and feature definitions 



5.1.1 PHL service definitions 

For the purpose of the present document, the definitions of EN 301 649 [15], clause 4.3.1 shall apply. 

5.1 .2 MAC service definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.2 shall apply. 

5.1 .3 DLC service definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.3 shall apply. 

5.1.4 NWK feature definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.4 plus the following shall 
apply: 

General Light Data Service Procedures [NGLDS-N.l]: NWK layer procedures needed for the operation of this 
profile. 

Software upgrade over the air, C-plane [NGLDS-N.2]: NWK layer procedures needed for upgrading the software of 
the PP. 
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5.1 .5 Application service definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.5 plus the following shall 
apply: 

Binary content download [NGLDS-A.l]: Ability to download binary files (or other) from a content server using 
HTTP protocol. 

Software upgrade over the air [NGLDS-A.l] : Ability to upgrade the software of the PP. 

HTTP-based applications [NGLDS-A.3]: Ability to browse HTML pages from the PP. 

5.1 .6 Management Entity (ME) definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.7 shall apply. 

5.1 .7 Call Control (CC) and mobility management service definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.8 shall apply. 

5.1 .8 U-plane service and interworking definitions 

For the purposes of the present document, the definitions of EN 301 649 [15], clause 4.3.9 shall apply. 



Profile specific requirements 



6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures), which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 

New Generation DECT; part 4 is defined as an application specific access profile of DPRS [15]. All procedures not 
specific to the New Generation DECT, part 4, are referenced to their original description in EN 301 649 (DPRS) [15]. 

The requirements of EN 301 649 [15] relevant for Class 2, Class 3 or Class 4 (depending on the supported Class(es)) 
equipment shall apply with the modifications stated, if needed, in clause 7 of the present document. 

The encapsulation of external data protocol shall be done as stated in EN 301 649 [15], clause B.8 (Generic media 
encapsulation) and clause B.8. 3.4 (HTTP limited set nr. 2). 

NOTE: The HTTP limited set nr. 2 (EN 301 649 [15], clause B.8. 3.4) implements the mandatory requirements of 
the present document (see clauses 7.6, A.l and A.2). The HTTP limited set nr. 2, contrarily to the HTTP 
limited set nr. 1 (EN 301 649 [15], clause B.8. 3. 3), does not require that all FP implementations include a 
full HTTP implementation. Some FPs could even be designed to be as transparent as possible from the 
application-layer point of view (i.e. HTTP), relying on the HTTP subset implemented by the PP to ensure 
the dialog with the server. One of the reasons for this is that full-featured browsing is not among the first 
targeted applications of the present document (although some PP implementations could be rich enough 
to allow it). Also, some of the targeted applications could rely on a NG-DECT part 4 specific server 
(a server implementing the requirements of the present document), thus purposely restricting the set of 
HTTP features used on server side. 
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In any case, the requirements of EN 300 176-1 [9], EN 300 176-2 [10] and any of the harmonized standard 
EN 301 406 [11] shall be met by all equipment conforming to the present document. 

The requirements tables in the following clauses are derived from the EN 301 649 [15]. In the service to procedure and 
feature to procedure mapping tables, the status of each particular item is explicitly stated only when it constitutes a 
change to the status indicated in EN 301 649 [15]. 

6.2 General class/service/interworking support 
6.2.1 Class/service support 

The following service classes and end-user services shall be supported by New Generation DECT, part 4 equipment. 

Table 3: General class and service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-G.1 


DPRS Glass 1 


4.3.8(15] 


1 


1 


DPRS-G.2 


DPRS Glass 2 


4.3.8 [15] 








DPRS-G.3 


Frame Relay (FREL) 


4.3.9 [15] and 
annex B [15] 


M 


M 


DPRS-G.4 


Character stream 


4.3.9 [15] and 
annexe [15] 


1 


1 


DPRS-G.5 


DPRS Class 3 


4.3.9 [15] and 
annexe [15] 








DPRS-G.6 


DPRS Class 4 


4.3.9 [15] and 
annexe [15] 


M 


M 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.2.2 Protocol interworking support 

The following protocol interworking modes shall be supported by New Generation DECT, part 4 equipment. 

Table 4: General service/interworking support 





Status 1 


Service 


Interworking 


Reference 


PT 


FT 


DPRS-G.3, Frame Relay (FREL) 




4.3.9 [15] and 
annex B [15] 


M 


M 




DPRS-1.1, Ethernet 


4.3.9 [15] and B.4 [15] 


1 


1 




DPRS-1.2, Token Ring 


4.3.9 [15] and B.5 [15] 


1 


1 




DPRS-1.3, IP 


4.3.9 [15] and B.6 [15] 


1 


1 




DPRS-1.4, PPP 


4.3.9 [15] and B.7 [15] 


1 


1 




DPRS-1.5, Generic media encapsulation 


4.3.9 [15], B.8 [15] and 
7.6.1.2 (see note 2) 


M 


M 


DPRS-G.4, Character stream 




4.3.9 [15] and 
annexe [15] 


1 


1 




DPRS-1.6, V.24 


4.3.9 [15] and C.4 [15] 


1 


1 


NOTE 1 : The reference column refers to the relevant clause in the present or in the referenced document. 
NOTE 2: The applicable clauses in 7.6.1 .2 according to table 1 3 shall apply. 



On regard to the Interworking conventions, the specific interworking requirements described in clause 7.7 shall also 
apply. 
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6.3 



Void 



6.4 Physical layer (PHL) requirements 
6.4.1 Physical layer (PHL) services 

New Generation DECT, part 4 devices shall support the following Physical layer (PHL) services. 

Table 5: Physical layer service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


DPRS-P.1 


GFSK modulation 


4.3.1 [15] 


M 


M 


DPRS-P.2 


7t/2 DBPSK modulation 


4.3.1 [15] 








DPRS-P.3 


7t/4 QBPSK modulation 


4.3.1 [15] 








DPRS-P.4 


7t/8 D8PSK modulation 


4.3.1 [15] 








DPRS-P.5 


16 QAM modulation 


4.3.1 [15] 








DPRS-P.6 


64 QAM modulation 


4.3.1 [15] 








DPRS-P.7 


Physical Packet P32 


4.3.1 [15] 








DPRS-P.8 


Physical Packet P64 


4.3.1 [15] 


M 


M 


DPRS-P.9 


Physical Packet P67 


4.3.1 [15] 








DPRS-P.10 


Physical Packet P80 


4.3.1 [15] 








DPRS-P.1 1 


General PHL 


4.3.1 [15] 


M 


M 


DPRS-P.12 


Fast hopping radio 


4.3.1 [15] 








NOTE: The reference column refers to the relevant clause in the referenced document. 



6.4.2 IVIodulation schemes 

The following modulation schemes defined by EN 300 175-2 [2], annex D shall be supported. 

Table 6: Allowed combinations of modulation schemes 



Modulation 
scheme 


S-fleld 


A-field 


B + Z-field 


Support status 


la 


GFSK 


GFSK 


GFSK 


M 


lb 


7t/2-DBPSK 


7t/2-DBPSK 


7t/2-DBPSK 


Q 


2 


7t/2-DBPSK 


7t/2-DBPSK 


7t/4-DQPSK 


Q 


3 


7t/2-DBPSK 


7t/2-DBPSK 


7t/8-D8PSK 


Q 


5 


7t/2-DBPSK 


7t/2-DBPSK 


16 QAM 


Q 


6 


7t/2-DBPSK 


7t/2-DBPSK 


64 QAM 


Q 



6.4.3 PHL service to procedure mapping 

The PHL service to procedure mapping of EN 301 649 [15], clause 5.3 shall apply. 
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6.5 MAC layer requirements 



6.5.1 MAC layer services 

New Generation DECT data devices shall support the following MAC layer services. 

Table 7: MAC service support 





Item 


Name of service 


Reference 


Support status 




PT 


FT 


DPRS-M.1 


General 


4.3.2 [15] 


M 


M 


DPRS-M.2 


Non continuous broadcast 


4.3.2 [15] 








DPRS-M.3 


Continuous broadcast 


4.3.2 [15] 


M 


M 


DPRS-M.4 


Paging broadcast 


4.3.2 [15] 


M 


M 


DPRS-M.5 


B-field advanced connection control 


4.3.2 [15] 








DPRS-M.6 


lpy_error_detection 


4.3.2 [15] 


M 


M 


DPRS-M.7 


lpy_error_correction 


4.3.2 [15] 








DPRS-M.8 


U-plane point-to-multipoint service 


4.3.2 [151 


1 


1 


DPRS-M.9 


Cg higher layer signalling 


4.3.2 [15] 


M 


M 


DPRS-M.1 


Cp higher layer signalling 


4.3.2 [15] 








DPRS-M.11 


Encryption activation 


4.3.2 [15] 


M 


M 


DPRS-M.1 2 


Encryption deactivation 


4.3.2 [15] 


C73 


C73 


DPRS-M.1 3 


Ouality control 


4.3.2 [15] 


M 


M 


DPRS-M.14 


Physical channel selection 


4.3.2 [15] 


M 


M 


DPRS-M.15 


SARI support 


4.3.2 [15] 


M 





DPRS-M.1 6 


DPRS Bearer handover 


4.3.2(15] 


M 


M 


DPRS-M.1 7 


Fast setup 


4.3.2 [15] 


C74 


C74 


DPRS-M.18 


Connection handover 


4.3.2 [15] 








DPRS-M.1 9 


Gp channel 


4.3.2 [15] 


C76 


C76 


DPRS-M.20 


lpQ_error_detection 


4.3.2 [15] 








DPRS-M.21 


lpQ_error_correction 


4.3.2 [15] 








DPRS-M.22 


lpx_encoded protected 


4.3.2 [15] 


C75 


C75 


DPRS-M.23 


Ipp channel 


4.3.2 [15] 


C76 


C76 


DPRS-M.24 


Full slot 


4.3.2 [15] 








DPRS-M.25 


Long slot 640 


4.3.2 [15] 


M 


M 


DPRS-M.26 


Long slot 672 


4.3.2 [15] 








DPRS-M.27 


Double slot 


4.3.2 [15] 








DPRS-M.28 


Multibearer connections 


4.3.2 [15] 


C74 


C74 


DPRS-M.29 


Asymmetric connections 


4.3.2 [15] 


C74 


C74 


DPRS-M.30 


Simplified A-field advanced 
connection control 


4.3.2 [15] 


M 


M 


C73 
C74 
C75 
C76 


IF DPRS-N.28 or DPRS-N.29 then M else 1. 

IF DPRS-M.5 THEN ELSE!. 

IF DPRS-P.5 (16 QAM) OR DPRS-P.6 (64 0AM) THEN M ELSE 0. 

IF DPRS-M.29 THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.5.2 IVIAC service to procedure mapping 

The MAC layer service to procedure mapping specified in EN 301 649 [15], clause 6.2, with the following changes and 
additional features shall apply. 
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Table 8: MAC service to procedure mapping 





Status 1 


Service 


Procedure 


Reference 
(clause) 


PT 


FT 


DPRS-M.1 General 




4.3.2 [15] 


M 


M 




Frame and IVIultiframe structure 


10.1.1 [15] 


M 


M 




Bit mappings 


10.1.2 [15] 


M 


M 




Scrambling 


10.1.4 [15] 


M 


M 




Error control 


10.1.5 [15] 


M 


M 




RFP idle receiver scan sequence 


10.1.8 [15] 


M 


M 




PT states and state transitions for 
PTs not supporting fast setup 


10.1.10.1 [15] 


C802 


C802 




Identities 


10.1.11 [15] 


M 


M 




A-field Multiplexer (T-MUX) 


10.21.1 [15] 


M 


M 




B-field control Multiplexer (E/U-MUX), 
basic modes 


10.21.2.1 [15] 


C804 


C804 


DPRS-M.2 Non continuous broadcast 




4.3.2 [15] 










Request for specific Q channel 
information 


10.2.1 [15] 










Request for a new dummy 


10.2.2 [15] 








DPRS-M.3 Continuous broadcast 




4.3.2 [15] 


M 


M 




Downlink broadcast 


10.3 [15] 


M 


M 


DPRS-IVI.4 Paging broadcast 




4.3.2 [15] 


M 


M 




Paging messages 


10.4.1 [15] 


M 


M 




MAC layer information messages 
procedures 


10.4.2 [15] 


M 


M 




LCE paging procedure 


10.4.3.1 [15] 


M 


M 




MAC paging procedure 


10.4.3.2 [15] 


C801 


C801 




Paging detection: High duty cycle 
(when there is an active virtual 
connection in suspend state) 


10.4.4.2 [15] 


C809 


C809 




Paging detection: High duty cycle 
(when there is no active virtual 
connection) 


10.4.4.2 [15] 










Paging detection: Normal duty cycle 
(when there is an active virtual 
connection in suspend state) 


10.4.4.1 [15] 


C810 


C810 




Paging detection: Normal duty cycle 
(when there is no active virtual 
connection) 


10.4.4.1 [15] 


C811 


C811 




Paging detection: Low duty cycle 
(when there is no active virtual 
connection) 


10.4.4.3 [15] 








DPRS-IVI.5 B-field advanced 
connection control 




4.3.2 [15] 










Fast setup 


10.10.1.2 [15] 










idle-locked state with set-up detection 


11.1.3.2 [3] 





1 




Logical connection setup 


10.5 [15] 


M 


M 




Logical connection release 


10.6 [15] 


M 


M 




Connection modification to change 
bandwidth (including suspend) 


10.7.1 [15] 


M 


M 




Connection modification to change 
MAC service type 


10.7.2.1 [15] 










Connection modification to change 
slot type 


10.7.2.2 [15] 










Connection modification to change 
modulation scheme or adaptive codec 
rate 


10.7.2.3 [15] 










B-field Single bearer Physical 
connection setup 


10.8.1 [15] 


M 


M 




B-field Physical Connection release 


10.9 [15] 


M 


M 




B-field Single duplex bearer setup 


10.10.1 [15] 


M 


M 
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Status 


Service 


Procedure 


Reference 
(clause) 


PT 


FT 




Usage of channel list messages 


10.10.1.3 [15] 


M 


M 




B-field Crossed bearer release 


10.11.2 [15] 










B-fleld Unacknowledged bearer 
release 


10.11.1 [15] 


M 


M 




B-field Acknowledged bearer release 


10.11.3 [15] 








DPRS-M.8 U-plane point-to-multipoint 
service 




4.3.2 [15] 


1 


1 




Connectionless Sip mode 


10.13.3 [15] 


M 


M 


DPRS-M.9 Cg liigtier layer signalling 




4.3.2 [15] 


M 


M 




Cg channel data 


10.14.1 [15] 


M 


M 


DPRS-M.1 Cp liigher layer signalling 




4.3.2 [15] 










Cp channel data 


10.14.2 [15] 


M 


M 




B-field control Multiplexer (E/U-MUX), 
Cp modes 


10.21.2.2 [15] 


M 


M 


DPRS-M.11 Encryption activation 




4.3.2 [15] 


M 


M 




Encryption process - initialization and 
synchronization 


10.15.1 [15] 


M 


M 




Encryption mode control 


10.15.2 [15] 


M 


M 




Encryption handover control 


10.15.3 [15] 


M 


M 


DPRS-M.1 2 Encryption deactivation 




4.3.2 [15] 


C73 


C73 




Encryption mode control 


10.15.2 [15] 


M 


M 


DPRS-M.1 3 Quality control 




4.3.2 [15] 


M 


M 




RFPI handshake 


10.16.1 [15] 


M 


M 




PT frequency correction procedure 


10.16.2 [15] 










Bearer quality report 


10.16.3 [15] 


M 


M 




Bearer quality report for asymmetric 
bearers {MAC-mod2-ACK) 


10.16.3.1 [15] 


C803 


C803 




Bearer and connection control 


10.16.4 [15] 










A-CRC handshake 


10.16.5 [15] 


M 


M 


DPRS-M.1 4 Physical channel 
selection 




4.3.2 [15] 


M 


M 




Physical channel selection 


10.17[15] 


M 


M 


DPRS-M.15 SARI support 




4.3.2 [15] 


M 







Downlink broadcast 


10.3.2.3 [15] 


M 


M 


DPRS-M.1 6 DPRS Bearer handover 




4.3.2 [15] 


M 


M 




B-field MAC Bearer replacement 
procedure 


10.18 [15] 


C804 


C804 




B-field MAC Bearer handover 
procedure 


10.19[15] 


C805 


C805 




A-field Bearer handover request (Mj) 


10.23.4 [15] 


C806 


C806 


DPRS-M.1 7 fast setup 




4.3.2 [15] 


C74 


C74 




FT initiated initial duplex bearer setup 


10.10.1.3 [15] 


M 


M 




PT receiver scan sequence 


10.1.9 [15] 


M 


M 




Fast setup control in MAC resume 
and control page message 


10.4.3.2.2 
[151 


M 







PT states and state transitions for 
PTs supporting fast setup 


10.1.10.2 [15] 


M 


M 




Listen for setup control codes in 
Release message 


10.11.6 [15] 


M 


M 


DPRS-M.1 8 Connection handover 




4.3.2 [15] 










B-field Advanced connection 
handover 


10.12 [15] 


C804 


C804 




A-field connection handover request 
(MT) 


10.23.5 [15] 


C806 


C806 


DPRS-M.1 9 Gp channel 




4.3.2 [15] 


C76 


C76 




Gp channel transmission 


10.20.1.1 [15] 










Gp channel data reception 


10.20.1.2 [15] 


M 


M 


DPRS-M.6 
lpiyi_error_detection service 




4.3.2 [15] 


M 


M 
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Status 


Service 


Procedure 


Reference 
(clause) 


PT 


FT 




Type 3 : lp_ error_detection 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 7 : lp_error_detection 
asymmetric MAC service 


5.6.2.2 [3] 


C803 


C803 




Multi-subfield protected B-field 


6.2.1.3.3 [3] 


M 


M 




Q1/Q2 bit setting for : lp_ 
error detection 


10.8.1.3.2 [3] 


M 


M 




Protected 1 channel errordetect 
procedure 


10.13.1 [15] 


M 


M 


DPRS-M.7 
lpiyi_error_correction service 




4.3.2 [15] 










Type 4 : lp_ error_correction 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 8 : lp_ error_correction 
asymmetric MAC service 


5.6.2.2 [3] 


C803 


C803 




Multi-subfield protected B-field 


6.2.1.3.3 [3] 


M 


M 




MOD-2 protected channel operation 


10.8.2 [3] 


M 


M 




Protected 1 channel error_correct 
mode 


10.13.2 [15] 


M 


M 


DPRS-M.20 
lpQ_error_detection service 




4.3.2 [15] 










Type 3 : lp_error_detection 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 7 : lp_ error_detection 
asymmetric MAC service 


5.6.2.2 [3] 


C803 


C803 




Single-subfield protected B-field 


6.2.1.3.4(3] 


M 


M 




Q1/Q2 bit setting for : lp_ 
error detection 


10.8.1.3.2 [3] 


M 


M 




Protected 1 channel errordetect 
procedure 


10.13.1 [15] 


M 


M 


DPRS-M.21 
lpQ_error_correction service 




4.3.2 [15] 










Type 4 : lp_ errorcorrection 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 8 : lp_ error_correction 
asymmetric MAC service 


5.6.2.2 [3] 


C803 


C803 




Single-subfield protected B-field 


6.2.1.3.4(3] 


M 


M 




MOD-2 protected channel operation 


10.8.2 [3] 


M 


M 




Protected 1 channel error_correct 
mode 


10.13.2(15] 


M 


M 


DPRS-M.22 
lpx_encoded protected 




4.3.2(15] 


C75 


C75 




Type 5 : lp_ encodec protected 
symmetric MAC service 


5.6.2.1 [3] 


M 


M 




Type 9 : lp_ encodec protected 
asymmetric MAC service 


5.6.2.2 [3] 


C803 


C803 




Channel coding 


1.1 [3] 


M 


M 


DPRS-M.23 
Ipiy, channel 




4.3.2(15] 


C76 


C76 




B-field control Multiplexer (E/U mux), 
E+U mode 


10.22.2.3(15] 


M 


M 




Ipy channel general 


10.22.1 [15] 


M 


M 




Ipy channel advanced procedures 


10.22.2(15] 










Ipy channel error correct procedures 


10.22.3(15] 


C807 


C807 




SIpy channel 


10.22.4(15] 


C808 


C808 


DPRS-M.24 
Full slot 




4.3.2(15] 
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Status 


Service 


Procedure 


Reference 
(clause) 


PT 


FT 




D-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.1.2 [3] 


M 


M 




B-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.3.1.2 [3] 


M 


M 


DPRS-M.25 
Long slot 640 




4.3.2 [15] 


M 


M 




D-field mapping for the variable slot 
structure (physical packet POOj) with 
j = 640 


6.2.1.1.4 [3] 


M 


M 




B-field mapping for the half and long 
slot structure (physical packet POOj) 
with j = 640 


6.2.1.3.1.3 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2[15] 


M 


M 


DPRS-M.26 
Long slot 672 




4.3.2 [15] 










D-field mapping for the variable slot 
structure (physical packet POOj) with 
1 = 672 


6.2.1.1.4 [3] 


M 


M 




B-field mapping for the half and long 
slot structure (physical packet POOj) 
with j = 672 


6.2.1.3.1.3 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2[15] 


M 


M 


DPRS-M.27 
Double slot 




4.3.2 [15] 










D-field mapping for the double slot 
structure (physical packet P80) 


6.2.1.1.1 [3] 


M 


M 




B-field mapping for the double slot 
structure (physical packet P80) 


6.2.1.3.1.1 [3] 


M 


M 




Additional procedures for Long and 
double slots 


D.2[15] 


M 


M 


DPRS-M.28 Multibearer connections 




4.3.2 [15] 


C74 


C74 




Multi bearer Physical connection 
setup 


10.8.2 [15] 


M 


M 




IVIBC Multibearer control 


10.8.2.1 [15] 


M 


M 


DPRS-M.29 Asymmetric connections 




4.3.2 [15] 


C74 


C74 




Double simplex bearers 


10.10.2 [15] 


M 


M 




Upstream Double simplex bearer 
setup (B-field) 


10.10.2.2 [15] 


M 


M 




Downstream Double simplex bearer 
setup (B-field) 


10.10.2.2 [15] 


M 


M 




Fast bearer release 


10.11.3 [15] 


M 


M 




Unacknowledged double simplex 
bearer release 


10.11.1 [15] 


M 


M 




Acknowledged double simplex bearer 
release 


10.11.2 [15] 








DPRS-IVI.30 simplified A-field 
connection control 




4.3.2 [15] 


M 


M 




PT initiated A-field advanced bearer 
setup (MT) 


10.23.2 [15] 


M 


M 




Connection/bearer release (MT) 


10.23.3 [15] 


M 


M 
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Status 


Service 


Procedure 


Reference 
(clause) 


PT 


FT 




Connection modification to change 
MAC service type 


10.7.2.1 [15] 










Connection modification to change 
slot type 


10.7.2.2 [15] 








C73: 

C74: 

C75: 

C76: 

C801 

C802 

C803 

C804 

C805 

C806 

C807 

C808 

C809 

C810 

C811 


IF DPRS-N.28 or DPRS-N.29 THEN M ELSE 1. 

IF DPRS-M.5 THEN ELSE 1. 

IF DPRS-P.5 (16 QAM) OR DPRS-P.6 (64 QAM) THEN M ELSE 

IF DPRS-M.29 THEN M ELSE 0. 

IF DPRS-M.5 THEN M ELSE 0. 

IF DPRS-M.1 7 THEN 1 ELSE M. 

IF DPRS-M.29 THEM M ELSE 1. 

IF DPRS-M.5 THEM M ELSE 1. 

IF DPRS-M.5 THEM ELSE 1. 

IF DPRS-M.30 THEM M ELSE 1. 

IF DPRS-M.7 OR DPRS-M.21 THEM M ELSE 1. 

IF DPRS-M.8 THEM ELSE 1. 

IF {DPRS-ME.2 OR DPRS-ME.3) THEM ELSE 1. 

IF {DPRS-ME.2 OR DPRS-ME.3) THEM M ELSE 1. 

IF DPRS-N.8 THEM M ELSE 0. 


NOTE: The reference column refers to the relevant clause in EN 301 649 [15] or in the referenced 
document. 



6.6 DLC layer 

6.6.1 DLC layer services 

New Generation DECT, part 4 devices shall support the following DLC layer services. 

Table 9: DLC service status 





Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 


DPRS-D.1 


LU10 Enhanced Frame RELay service {EFREL) 


4.3.3 [15] 


M 


M 


DPRS-D.2 


FUlOa 


4.3.3 [15] 


M 


M 


DPRS-D.3 


FUlOb 


4.3.3 [15] 


1 


1 


DPRS-D.4 


FUlOc 


4.3.3 [15] 


M 


M 


DPRS-D.5 


Data Link Service (LAPC + Lc) class A service 


4.3.3(15] 


M 


M 


DPRS-D.6 


Data Link Service (LAPC + Lc) class U service 


4.3.3 [15] 








DPRS-D.7 


Lc Frame delimiting and sequencing service 


4.3.3 [15] 


M 


M 


DPRS-D.8 


Broadcast Lb service 


4.3.3 [15] 


M 


M 


DPRS-D.9 


Inter-cell voluntary connection handover 


4.3.3 [15] 








DPRS-D.10 


Connection modification 


4.3.3 [15] 


C92 


C92 


DPRS-D.1 1 


Encryption activation 


4.3.3 [15] 


M 


M 


DPRS-D.12 


Encryption deactivation 


4.3.3 [15] 


C91 


C91 


DPRS-D.13 


Connectionless U-plane 


4.3.3 [15] 


1 


1 


C91 : If DPRS-N.28 or DPRS-N.29 then M else 1. 
C92: {If DPRS-M.5 THEN M ELSE 0). 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.6.2 DLC service to procedure mapping 

The DLC layer service to procedure mapping specified in EN 301 649 [15], clause 7.2 shall apply. 
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6.7 NWK layer 



6.7.1 General 

The NWK layer provisions shall include the following entities: 

• Call Control (CC). 

• Mobility Management (MM). 

• Link Control Entity (LCE). 

• ConnectionLess Message Service (CLMS). 

New Generation DECT data equipment is based on DPRS Class 2 (see clause 4.3.8 [15]), and therefore requires a NWK 
layer. 

6.7.2 NWK features 

New Generation DECT data devices shall support the following NWK layer features. 

Table 10: NWK features status 



Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.1 


PT initiated virtual call 


4.3.4 [15] 


M 


M 


DPRS-N.2 


Off hook 


4.3.4 [15] 


M 


M 


DPRS-N.3 


On hook (full release) 


4.3.4 [15] 


M 


M 


DPRS-N.4 


Dialled digits (basic) 


4.3.4 [15] 








DPRS-N.5 


Register recall 


4.3.4 [15] 








DPRS-N.6 


Go to DTIVIF signalling (defined tone length) 


4.3.4 [15] 








DPRS-N.7 


Pause (dialling pause) 


4.3.4 [15] 








DPRS-N.8 


FT initiated virtual call 


4.3.4 [15] 








DPRS-N.9 


Authentication of PP 


4.3.4 [15] 


M 


M 


DPRS-N.10 


Authentication of user 


4.3.4 [15] 








DPRS-N.1 1 


Location registration 


4.3.4 [15] 


M 





DPRS-N.12 


On air key allocation 


4.3.4 [15] 


M 


M 


DPRS-N.13 


Identification of PP 


4.3.4 [15] 








DPRS-N.14 


Service class indication/assignment 


4.3.4 [15] 








DPRS-N.15 


Alerting 


4.3.4 [15] 








DPRS-N.16 


ZAP 


4.3.4 [15] 








DPRS-N.17 


Encryption activation FT initiated 


4.3.4 [15] 


M 


M 


DPRS-N.18 


Subscription registration procedure on-air 


4.3.4(15] 


M 


M 


DPRS-N.19 


Link control 


4.3.4 [15] 


M 


M 


DPRS-N.20 


Terminate access rights FT initiated 


4.3.4 [15] 


M 





DPRS-N.21 


Partial release 


4.3.4(15] 








DPRS-N.22 


Go to DTMF (infinite tone length) 


4.3.4 [15] 








DPRS-N.23 


Go to Pulse 


4.3.4 [15] 








DPRS-N.24 


Signalling of display characters 


4.3.4 [15] 








DPRS-N.25 


Display control characters 


4.3.4(15] 








DPRS-N.26 


Authentication of FT 


4.3.4(15] 








DPRS-N.27 


Encryption activation PT initiated 


4.3.4(15] 








DPRS-N.28 


Encryption deactivation FT initiated 


4.3.4(15] 
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Feature supported 


Features 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-N.29 


Encryption deactivation PT initiated 


4.3.4 [151 








DPRS-N.30 


Calling Line Identification Presentation (CLIP) 


4.3.4 [15] 








DPRS-N.31 


Internal call 


4.3.4 [15] 








DPRS-N.32 


Service call 


4.3.4 [15] 








DPRS-N.33 


Dynamic parameters allocation 


4.3.4 [15] 


C1001 


C1001 


DPRS-N.34 


Service Negotiation at virtual call setup 


4.3.4 [15] 


C1002 


C1002 


DPRS-N.35 


In call service change 


4.3.4 [15] 








DPRS-N.36 


NWK layer management 


4.3.4 [15] 


M 


M 


DPRS-N.37 


Identity assignment 


4.3.4 [15] 








DPRS-N.38 


DECT External handover 


4.3.4 [15] 








DPRS-N.39 


IVlessage Waiting Indication 


4.3.4 [15] 








DPRS-N.40 


Detach 


4.3.4 [15] 








DPRS-N.41 


Periodic location registration 


4.3.4 [15] 








DPRS-N.42 


On-air modification of user parameters 


4.3.4 [15] 








NGLDS-N.1 


General Light Data Service Procedures 


5.1.4 


M 


M 


NGLDS-N.2 


Software upgrade over the air, C-plane 


5.1.4 


M 


M 


CI 001: IF (DPRS-ME.2 OR multi-context supported (7.6.1.2.2) OR Generic multiprotocol supported (7.6.1.2.3) 

OR application packet size different from basic service settings (see EN 301 649 [15] clauses 12.22 

and A.2) THEN M ELSE 0. 
CI 002: IF DPRS-I\/IE.2 THEN M ELSE (IF (LU10 Interworking conventions and HTTP profile for enhanced 

binary content download (7.6.1.2.2) OR LU10 Interworking conventions and HI IP profile for Generic 

multiprotocol binary content download (7.6.1 .2.3) THEN ELSE X). 


NOTE: The reference column refers to the relevant clause in this or in the referenced document. 



6.7.3 NWK features to procedures mapping 

The NWK layer feature to procedure mapping specified in EN 301 649 [15], clause 8.2 with the following changes and 
additional features shall apply: 

Table 11 : NWK feature to procedure mapping 



Feature/Procedure mapping 


Status 1 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.1 , PT initiated virtual call 




4.3.4 [15] 


M 


M 




PT initiated virtual call request (outgoing 
call) 


7.5.1 


M 


M 




Overlap sending 


8.3 [14] 


M 







Outgoing call proceeding 


8.4 [14] 


M 







Outgoing call confirmation 


8.5 [14] 


M 







Outgoing call connection 


8.6 [14] 


M 


M 




Sending keypad information 


8.10 [14] 








DPRS-N.2, Off Hook 




4.3.4 


M 


M 




PT initiated virtual call request (outgoing 
call) 


7.5.1 


M 


M 




Incoming call connection 


8.15 [14] 


M 


M 


DPRS-N.8, FT initiated virtual call 




4.3.4 [15] 










FT initiated virtual call request (incoming 
call) 


7.5.2 


M 


M 




Incoming call confirmation 


8.13 [14] 


M 


M 




PT alerting 


8.14 [14] 


M 


M 




Incoming call connection 


8.15 [14] 


M 


M 


DPRS-N.1 1, Location registration 




4.3.4 [15] 


M 







Location registration 


8.28 [15] 


M 


M 




Location update 


8.29 [15] 


M 







Terminal capability indication 


7.5.7 


M 


M 


DPRS-N.1 7, Encryption activation FT 
initiated 




4.3.4 [15] 


M 


M 




Cipher-switching initiated by FT 


8.33 [14] 


M 


M 




Storing the Derived Cipher Key (DCK) 


8.27 [14] 


M 


M 




Enforcement of encryption 


7.5.4.3 


M 


M 
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Feature/Procedure mapping 


Status 


Feature 


Procedure 


Ref. 


PT 


FT 


DPRS-N.18, Subscription registration 
user procedure on-air 




4.3.4 [15] 


M 


M 




Obtaining access rights 


8.30 [15] 


M 


M 




Terminal capability indication 


7.5.7 


M 


M 


DPRS-N.19, Linl< control 




4.3.4 [15] 


M 


M 




Indirect FT initiated link establishment, for 
devices supporting complete MAC 
procedures. Initial setup paging. 


12.11.1.1 
[15] 


C1101 


C1101 




Indirect FT initiated link establishment, for 
devices supporting simplified (A-field) MAC 
procedures. Initial setup paging. 


12.11.2.1 
[15] 


C1 102 


C1 102 




Fast Paging 


12.12[15] 










Collective and group ringing 


12.13 [15] 










Direct FT initiated link establishment 


12.14 [15] 










Direct PT initiated link establishment 


8.36 [14] 


M 


M 




Link release "normal" 


8.37 [14] 


M 


M 




Link release "abnormal" 


8.38 [14] 


M 


M 




Link release "maintain" 


8.39 [14] 


1 


1 




Indirect FT initiated link establishment, for 
devices supporting complete MAC 
procedures. LCE Resume Paging 


12.11.1.2 

[15] 


C1101 


C1 103 




Indirect FT initiated link establishment, for 
devices supporting simplified (A-field) MAC 
procedures. LCE Resume Paging 


12.11.2.2 

[15] 


C1 104 


C1 104 


DPRS-N.24, Signalling of display 
characters 




4.3.4 










Display 


8.16 [15] 


M 


M 




Terminal capability indication 


7.5.7 


M 


M 


DPRS-N.25, Display control characters 




4.3.4 [15] 










Display 


8.16 [15] 


M 


M 




Terminal capability indication 


7.5.7 


M 


M 


DPRS-N.33, Dynamic parameters 
allocation 




4.3.4 [15] 


C1001 


CI 001 




Dynamic parameters allocation 


12.8 [15] 


M 


M 


DPRS-N.34, Service Negotiation at 
virtual call setup 




4.3.4 [15] 


CI 002 


CI 002 




Call Resources/Parameters negotiation 


7.5.8 


M 


M 




Service Negotiation specific rules 


7.5.3 


M 


M 


DPRS-N.35, In call service change 




4.3.4 [15] 










Service change - Bandwidth Change 


12.6.1 [15] 


C1105 


C1 105 




Slot type change 


12.6.2 [15] 










MAC Service change 


12.6.3 [15] 










Modulation type or adaptive codec rate 
change 


12.6.4 [15] 










DPRS Management Entity Class and other 
Call-attributes change 


12.6.5 [15] 










MAC Packet lifetime, DLC Window size, 
DLC Transit delay and Cp channel 

attributes change 


12.6.6 [15] 










IWU-attributes change - General 


12.7.1 [15], 
7.5.9 


M 


M 




Interworking type change 


12.7.2(15] 


1 


1 




IP address change (IP IWU) 


12.7.3 [15] 


1 


1 




Maximum SDL) size change 


12.7.4 [15] 








DPRS-N.36, NWK layer management 




4.3.4(15] 


M 


M 




Management of MM procedures 


12.18(15] 


M 


M 




Management - Location registration 
initiation 


13.2(14] 


M 


C1 107 




Management - Assigned individual TPUl 


13.3(14] 


M 


C1 107 




Management - PMID 


12.19(15] 


M 


M 




Management - DCK 


13.6(14] 


M 


M 




Management - Broadcast attributes 


7.5.10, 12.17 
[14] 


M 


M 
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Feature/Procedure mapping 


Status 


Feature 


Procedure 


Ref. 


PT 


FT 




Management - Storage of subscription 
related data 


13.7 [14] 


M 


M 




U-plane handling 


12.17 [15] 


M 


M 




Length of NWK layer messages 


12.20 [15] 


C1 108 


C1 108 




Identities 


12.21 [15] 


M 


M 












NGLDS-N.1 General Light Data Service 
Procedures 




5.1.4 


M 


M 




Service change rejection 


7.5.4.1 


M 


M 




Interaction with telephony service 


7.5.4.2 


M 


M 


NGLDS-N.2 Software upgrade over the 
air, G-plane 




5.1.4 


M 


M 




Information exchange in the C-Plane 


7.5.5 


M 


M 




SUOTA push mode 


7.5.6 










Enforcement of encryption 


7.5.4.3 


M 


M 


C1001 

C1002 
C1101 
C1102 
C1103 
C1 104 
C1 105 
C1 107 
C1 108 


IF (DPRS-ME.2 OR multi-context supported (7.6.1 .2.2) OR Generic multiprotocol supported (7.6.1 .2.3) OR 

application packet size different from basic service settings) THEN M ELSE 0. 

IF DPRS-ME.2 THEN M ELSE X. 

IFDPRS-M.5THEN M ELSE L 

IF DPRS-M.30 THEN (IF DPRS-N.8 OR DPRS-ME.1 THEN M ELSE 0) ELSE 1. 

IF DPRS-M.5 THEN (IF single cluster system THEN ELSE M) ELSE 1. 

IF DPRS-M.30 AND DPRS ME.3 THEN M ELSE 1. 

IF DPRS-ME.2 THEN M ELSE X. 

IFDPRS-N.11 THEN M ELSE 1. 

IF (DPRS-N.34 OR Generic multiprotocol supported (7.6.1 .2.3)) THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the present document, except where stated 
otherwise. 



6.8 Application features 
6.8.1 Application features 

New Generation DECT, part 4 devices shall support the following application features. 

Table 12: Application features status 



Feature supported 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


DPRS-A.1 


AC bitstring mapping 


4.3.5 [15] 


M 


M 


DPRS-A.2 


Multiple subscription registration 


4.3.5 [15] 





N/A 


DPRS-A.3 


Manual entry of the PARK 


4.3.5(15] 





N/A 


NGLDS-A.1 


Binary content download 


5.1.5 


M 


M 


NGLDS-A.2 


Software ugrade over the air 


5.1.5 


M 


M 


NGLDS-A.3 


HTTP based applications 


5.1.5 





M 


NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 



6.8.2 Application features to procedures mapping 

The Application feature to procedure mapping specified in EN 301 649 [15], clause 8.4 with the following additional 
features shall apply. 
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Table 13: Application feature to procedure mapping 



Feature/Procedure mapping 


Status 1 


Feature 


Procedure 


Ref. 


PT 


FT 


NGLDS-A.1 Binary content download 




5.1.5 


M 


M 




General Light Data Services [NGLDS-N.1] 


5.1.4 


M 


M 




Binary content download general 
requirements 


7.6.1.1 


M 


M 




LU10 Interworking conventions and HTTP 
profile for simple binary content download 


7.6.1.2.1 


M 


M 




LU10 Interworking conventions and HTTP 
profile for enhanced binary content 
download 


7.6.1.2.2 










LU10 Interworking conventions and HTTP 
profile for Generic multiprotocol binary 
content download 


7.6.1.2.3 










Binary content download media type 


7.6.1.3 


M 


M 




Binary content download sequence 


7.6.1.4 


M 


M 




URI-based PP to FP confidentiality 
requirement 


7.6.1.5.1 










URI-based PP to FP authentication 
requirement 


7.6.1.5.2 










PP to FP enhanced interactivity 


7.6.1.6 





M 




Common HTTP profile 


A.1 


M 


M 


NGLDS-A.2 Software upgrade over the 
air 




5.1.5 


M 


M 




Binary content download [NGLDS-A.1] 


5.1.5 


M 


M 




Software upgrade over the air, C-plane 
[NGLDS-N.2] 


5.1.4 


M 


M 




Software upgrade over the air general 
requirements 


7.6.2.1 


M 


M 




Basic SUOTA protocol steps 


7.6.2.2 


M 


M 




Enhanced SUOTA protocol steps 


7.6.2.3 


N/A 







PP security requirements in URL1 and 
URL2 


7.6.2.4 










Final notification of success and multiple 
step SUOTA 


7.6.2.5 


M 


M 




Notification of failure 


7.6.2.6 


M 


M 




User initiated SUOTA 


7.6.2.7 





M 




SUOTA interface to the management 
server 


B 


N/A 


M 


NGLDS-A.3 HTTP based applications 




5.1.5 





M 




Binary content download [NGLDS-A.1] 


5.1.5 


M 


M 




HTTP based applications general 
requirements 


7.6.3.1 


M 


M 




Support of additional HTTP header fields 


7.6.3.2 


M 


M 




Support of additional media-types 


7.6.3.3 


M 


M 




Support of character encodings 


7.6.3.4 


M 


M 




Simple XHTML profile 


7.6.3.5 


M 


M 




Baseline XHTML profile 


7.6.3.6 





M 




Extended HTTP profile 


A.2 


C1301 


M 


CI 301 : IF Baseline XHTML profile supported THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the present document. 



6.9 



Distributed communications 



The distributed communication mode (PP-PP communication) is not part of the present document. 
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Table 14: Distributed communication requirements 



Feature supported 


Status 1 


Feature 


Name of feature 


Ref. 


PT 


FT 


HyP 


DPRS-DC.1 


Distributed Communication 


4.3.6 [15] 


1 


1 


1 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.10 Management Entity (ME) 

6.1 0.1 Management Entity (IVIE) operation modes 

In regard to the New Generation DECT, part 4equipment, the following ME operation modes from EN 301 649 [15], 
clause 9. 1 shall apply. 

Table 15: IVIanagement Entity Requirements 



Feature supported 


Status 1 


Feature 


Name of feature 


Ref. 


PT 


FT 


DPRS-ME.1 


Class 1 management 


4.3.7(15] 


1 


1 


DPRS-ME.2 


Class 2 management 


4.3.7 [15] 








DPRS-ME.3 


Class 3 management 


4.3.7 [15] 








DPRS-ME.4 


Class 4 management 


4.3.7 [15] 


M 


M 


NOTE: The reference column refers to the relevant clause in the referenced document. 



6.1 0.2 Management Entity (ME) mode to procedures mapping 

In regard to the New Generation DECT, part 4 equipment, the operation mode to procedure mapping specified in 
EN 301 649 [15], clause 9.1.2 shall apply. 



Profile specific procedures description 



7.1 



General 



This clause identifies differences and additions to the feature/service/procedure definitions and descriptions as specified 
in EN 301 649 [15], DPRS. 



7.2 



Management Entity (ME) procedures 



No differences/additions - the procedures as specified in EN 301 649 [15], clauses 9 and A.l shall apply. 



7.3 MAC layer procedures 



No differences/additions - the procedures as specified in EN 301 649 [15], clause 10 shall apply. 



7.4 DLC layer procedures 



No differences/additions - the procedures as specified in EN 301 649 [15], clause 11 shall apply. 
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7.5 NWK layer procedures 



The procedures as specified in EN 301 649 [15], clause 12 shall apply with the modifications and additional procedures 
listed in the present clause. 



7.5.1 



PT initiated virtual call request (outgoing call) 



The following text together with the associated clauses defines the mandatory requirements with regard to the present 
document: 

The procedure shall be performed as defined in EN 300 444 [14], clause 8.12 with the following specific provisions: 

The information elements supported by the CC-SETUP message depends on the support of feature DPRS-N.34 (Service 
negotiation): 

If feature DPRS-N.34 is not supported, then: 

• the Information element «Basic Service» shall be transmitted; 

• the field <basic service> in the IE «Basic service» shall be set to one of the following basic services defined 
in EN 300 175-5 [5]: 

basic service = Light data service with ME Class 4 (code= 'lOOl'B); 

basic service = Light data service with ME Class 3 (code= 'lOlO'B); 

• the Information elements « IWU ATTRIBUTES », « CALL ATTRIBUTES », « CONNECTION 
ATTRIBUTES », « TRANSIT DELAY » and « WINDOW SIZE » shall not be transmitted; 

• the virtual call can only be setup with initial parameters as defined by the basic service. 

If feature DPRS-N.34 is supported, then all information elements described in the procedures associate to this feature 
may be used. In this case the IE «Basic Service (basic service = other) may be used. The IE «Basic Service (basic 
service = light data service with ME Class 4 or light data service with ME Class 3)» may also be used defining a 
default setting for all parameters not transmitted in the lEs. 

NOTE 1: Any parameter transmitted in any of the lEs supersedes the default setting done by the "Basic service". 

In any case (DPRS-N.34 supported or not), the parameters of the call may be changed after setup using the feature 
DPRS-N.35, if supported. 

NOTE 2: If neither feature DPRS-N.34 nor DPRS-N.35 are supported, then only calls with parameter setting equal 
to the basic service may be set up. 

Table 16: Values used within the {CC-SETUP} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« Basic service » 










< Basic service > 


'1001'B 


Light data service default setup 
attributes with ME Class 4 (see note 2) 




< Basic service > 


'1010'B 


Light data service default setup 
attributes with ME Class 3 (see note 2) 




< Basic service > 


'1111'B 


Other 


NOTE 1 : For tlie additional information elements needed to identify the required service/parameters see 

DPRS-N.34 Service Negotiation feature. 
NOTE 2: Default light data service setup attributes are described in clause A.2 of DPRS (EN 301 649 [15]). 
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7.5.2 FT initiated virtual call request (incoming call) 

The following text together with the associated clauses defines the mandatory requirements with regard to the present 
document. 

The procedure shall be performed as defined in EN 300 444 [14], clause 8.12 with the following specific provisions. 

The information elements supported by the CC-SETUP message depends on the support of feature DPRS-N.34 (Service 
negotiation). 

If feature DPRS-N.34 is not supported, then: 

• The Information element «Basic Service» shall be transmitted; 

• The field <basic service> in the IE «Basic service» shall be set to one of the following basic services 
defined in EN 300 175-5 [5]: 

Basic service = Light data service with ME Class 4 (code= 'lOOl'B); 

Basic service = Light data service with ME Class 3 (code= 'lOlO'B); 

• The Information elements « IWU ATTRIBUTES », « CALL ATTRIBUTES », « CONNECTION 
ATTRIBUTES », « TRANSIT DELAY » and « WINDOW SIZE » shall not be transmitted; 

• The virtual call can only be setup with initial parameters as defined by the basic service. 

If feature DPRS-N.34 is supported, then all information elements described in the procedures associated to this feature 
may be used. In this case the IE «Basic Service (basic service = other) may be used. The IE «Basic Service (basic 
service = light data service with ME Class 4 or light data service with ME Class 3)» may also be used defining a 
default setting for all parameters not transmitted in the lEs. 

NOTE 1: Any parameter transmitted in any of the lEs supersedes the default setting done by the "Basic service". 

In any case (DPRS-N.34 supported or not), the parameters of the call may be changed after setup using the feature 
DPRS-N.35, if supported. 

NOTE 2: If neither feature DPRS-N.34 nor DPRS-N.35 are supported, then only calls with parameter setting equal 
to the basic service may be set up. 

Table 17: Values used within the {CC-SETUP} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« Basic service » 










< Basic service > 


'1001'B 


Light data service default setup 
attributes with ME Class 4 (see note 2) 




< Basic service > 


'1010'B 


Light data service default setup 
attributes with ME Class 3 (see note 2) 




< Basic service > 


'1111'B 


Other 


NOTE 1 : For tlie additional information elements needed to identify the required service/parameters see 

DPRS-N.34 Service Negotiation feature. 
NOTE 2: Default light data service setup attributes are described in clause A.2 of DPRS (EN 301 649 [15]). 
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7.5.3 Service Negotiation specific rules 



The additional Information elements described as part of feature DPRS-N.34 shall be used in calls using Management 
Class 2 (DPRS-ME.2) and may only be used in Calls using ME.4 (mandatory mode) or ME. 3 when both peers have 
announced (in «SETUP CAPABILITY» the support of the procedures "LUlO Interworking conventions and HTTP 
profile for enhanced binary content download" (see clause 7.6.1.2.2) or "LUlO Interworking conventions and HTTP 
profile for Generic multiprotocol binary content download" (see clause 7.6.1.2.3). Calls using ME.4 or ME.3 when any 
of the peers only supports the basic procedure "LUlO Interworking conventions and HTTP profile for simple binary 
content download" (see clause 7.6.1.2.1) shall be always set up using basic service IE and shall not use the IE part of 
DPRS-N.34. The parameters of the call may be changed after initial set up using Service Change (DPRS-N.35) if 
supported. 

NOTE 1: If neither feature DPRS-N.35 nor DPRS-N-34 are supported, only calls with parameter setting equal to 
the basic service may exist. 

NOTE 2: The rule is intended for implementations supporting DPRS-N.34 due to the support of DPRS-ME.2, or 
any of the optional binary content download procedures, when initiating a call with a peer that does not 
support DPRS-N.34, in order to avoid the rejection of the setup due to the lack of support of DPRS-N.34 
by the other side. 

7.5.4 General procedures 

This clause lists specific general procedures applicable to all services provided by this profile. 

7.5.4.1 Service change rejection 

Any implementation not supporting the feature DPRS-N.35 (Service change) shall at least be able to reject an incoming 
{CC-SER VICE-CHANGE} message with a {CC-SERVICE-REJECT}, even if the implementation does not understand 
completely the message because it does not support the handling of long NWK layer messages 
(EN 301 649 [15], clause 12.20). 

7.5.4.2 Interactions with telephony service 

This clause describes the applicable procedure to solve the possible interactions in devices (PP or FP) implementing the 
present document and also a voice telephony service as described in EN 300 444 (GAP) [14], TS 102 527-1 [16] or 
TS 102 527-3 [17]. 

The procedures described in the present clause determine the basic rules for handling the interaction. The following 
subprocedures are provided and shall be supported by all devices implementing the present document plus any voice 
telephony service (either EN 300 444 (GAP) [14], TS 102 527-1 [16] or TS 102 527-3 [17]): 

• Switching procedure when a light data service call is already established and there is an incoming voice call. 

• Using a light data service when a voice call is already established. 

• Handling of other interactions. 

The procedures for simultaneous handling of light data service and voice calls require further study and will be added in 
future revisions of the present document. 
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7.5.4.2.1 Switching procedure when a light data service call is already established and 

there is an incoming voice call 

This clause describes the behaviour of systems which do not support simuhaneously data and voice calls but that may 
however switch from data to voice calls, when an incoming voice call happens during a light data service call. It 
provides the mechanisms for notification of a possible incoming voice call when a data call is in progress, and for 
possible switching between the calls. 

Setting the "Support of simultaneous DPRS and voice calls " flag in «SETUP CAPABILITY» 

The PP and FP shall set correctly the « SETUP-CAPABILITY » IE, bits 4, 5 of octet 4 "Support of simultaneous 
DPRS and voice calls". 

All devices implementing the present document plus any voice telephony service (either GAP (EN 300 444 [14]), 

TS 102 527-1 [16] or TS 102 527-3 [17]) shall support and at least "Simultaneous DPRS and voice calls not supported, 

however switching procedure supported". 

If PP or FP supports more enhanced behaviours (simultaneous voice and data calls active or not): 

• This entity shall align its behaviour to the remote entity capability if it is lower. 

• Those more enhanced behaviours are not defined in detail in this version of the current specification. 

NOTE 1: The explicit setting of bits 4, 5 of octet 4 in « SETUP-CAPABILITY » is only needed in devices 

supporting the feature DPRS-N.33 "Dynamic parameters allocation". For devices that only support the 
behaviour defined in a basic service, the proper setting of the bits is already included in the basic service 
definition. See EN 301 649 (DPRS) [15], clause A.2. 

Incoming voice call during preliminary exchanges of the SUOTA process 

If an incoming internal or external call occurs while the PP has started a SUOTA process: 

• either PP and FP are exchanging C-plane «IWU-WU» commands; 

• or PP is upgrading its memory due to the firmware upgrade. 

The FP shall present the incoming voice call as a standard incoming call to the PP. The PP may process or ignore this 
incoming call. 

NOTE 2: Call might not even be presented to the user on PP side. However this should be carefully handled by the 
PP as this is considered as a temporary interruption of the telephony service for the user. 

Incoming voice call while Ught data service call is already established 

This clause describes how to process an incoming internal or external voice call when a data connection is already 
established. The data call may be related to any of the light data services. 

When receiving an incoming internal or external voice call during an ongoing light data service call, the following 
procedures of TS 102 527-3 [17] shall be used with the modifications stated in the present document: 

• "Call waiting indication (external or internal)", see TS 102 527-3 [17], clause 7.4.3.5.2. 

• "Call waiting rejection", see TS 102 527-3 [17], clause 7.4.3.5.7. 

• "CLIP on call waiting" see TS 102 527-3 [17], clause 7.4.3.5.10. 

• "CNIP on call waiting", see TS 102 527-3 [17], clause 7.4.3.5.11. 

For the PP involved in the light data service, the FP shall indicate the incoming voice call using the "Call waiting 
indication (external or internal)" procedure of TS 102 527-3 [17], additionally the FP shall use the "CLIP on call 
waiting" as well as "CNIP on call waiting" procedures of TS 102 527-3 [17]. 
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When receiving this call waiting indication, the PP shall decide between any of the following options: 

• Either continue with the light data service call (and ignore the call waiting). 

EXAMPLE: This may be the case when the PP is involved in a critical step of a Software update procedure. 

• Or reject the incoming call using the "Call waiting rejection (from PP to FP)" procedure of TS 102 527-3 [17]. 

• Or switch from the data call to the voice call. For this, the PP shall release it using a {CC-RELEASE} 
message. The FP shall answer with a {CC-RELEASE-COM} message. If the voice call is still waiting, the FP 
shall re-present the incoming call by sending a {CC-SETUP} message. See figure 5 below for details of data 
service to voice call switching procedure. 

• The decision taken by the PP shall be based on the type of light data service, the state of the process, its own 
implementation capabilities, and may involve, or not, interaction with the end-user. 

NOTE 3: In the PP is performing a Software Upgrade over the air, the PP is responsible to ensure that the decision 
taken does not compromise its vital functions. 

In the meantime, if the remote party desists from the call, or if another PP accepts the call, the FP shall use the " call 
release and call release rejection" procedure of TS 102 527-3 [17] to inform the PP that the incoming voice call is no 
longer relevant (use of call status CS idle). The PP shall, in this case, not continue with the switching procedure. See 
figure 6 for details. 
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PP 



FP 




Ongoing data call 




CC-INFO 



Line on which waiting call 

if required by the line Id feature 



Line on which waiting call 
if required by line Id feature 



PP accepts the incoming 
voice voice call 



Incoming call further 

process as a regular 

incoming voice call 



« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', value = 'waiting call id' ■- 
'01'H> 

< id type/subtype = 'Call status', value = 'CS call setup' > 

CC-INFO 




« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', value = 'waiting call id' 
'01 'H> 

>> CC-INFO 



« CALLING PARTY NAME » 

« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', val = 'waiting call id' = 
'01 'H> 

» CC-RELEASE 



CC-RELEASE-COM 



LCE-REOUEST-PAGE 



CC-SETUP 



CC-ALERTING 



CC-CONNECT 




Voice call connected. 




Incoming voice 
call 



After the release of the 
data call, the FP pages the 
PP indicating that there is 
an incoming voice call 



Figure 5: Incoming voice call accepted by the user during established data call 
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PP 



FP 





^1 r^ 




<C^ Ongoing data call J^ 




CC-INFO 




« CALL-INFORMATION. 


Line on which waiting call < id type = 'Line identifier', subtype = 'external call', 
if required by the line Id feature value = 'waitina call line id' > 




< id type/subtype = 'Call identifier', value = 'waiting call id' = 
'01 'H> 

< id type/subtype = 'Call status', value = 'CS call setup' > 
» 

CC-INFO 




« CALLING PARTY NUMBER, 

< Calling Party Address = 'calling number' > » 

« CALL-INFORMATION. 


Line on which waiting call < jd type = 'Line identifier', subtype = 'external call', 
if required by line Id feature value - 'waitina call line id' > 




< id type/subtype = 'Call identifier', value = 'waiting call id' = 
■01 'H> 

CC-INFO 




« CALLING PARTY NAME » 
« CALL-INFORMATION, 

< id type/subtype = 'Call identifier', val = 'waiting call id' = 
'01'H> 

^^ CC-INFO 




« CALL-INFORMATION, 

< id type = 'Line identifier', subtype = 'external call', 

value = 'waiting call line id' > 

< id type/subtype = 'Call identifier', value = 'waiting call id' = 
'01'H> 

< id type/subtype = 'Call status', value = 'CS idle' > 
» 




<C1^ Same data call still ongoing J^^^^^^l^ 




^ 1^ 



Incoming voice 
call 




Call accepted on an 
other PP or terminated 
by remote party 



Figure 6: Incoming voice call during a data call but accepted on an other PP 

or terminated by remote party 

Behaviour when there are several PPs in the cell 

If there further PPs in the FP cell, not involved in a data call as described in the present document (either because they 
do not implement it, or because there is no active call), the regular procedures described in EN 300 444 [14] (GAP), 
TS 102 527-1 [16] or TS 102 527-3 [17] (as supported by the PP) shall be used with these PPs with no modifications. 

If the FP is configured to page all, or several, PPs, when an incoming call arrives, the FP shall use the procedure 
described in the present clause for notifying the call to the PP (or PPs) that is(are) involved in a data call, and 
simultaneously shall use the standard LCE paging procedure (according to the voice profile supported) to notify all 
other PPs of the incoming call. The paging procedure for other PPs shall not be delayed waiting for the completion or 
response of the PP(s) which is(are) involved in the data call. 
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7.5.4.2.2 Simultaneous handling of light data service and voice calls 

More advanced terminals (PP or FP) may implement the following procedures: 

• Simultaneous handling of data and voice calls, but with only one active call at a time (the data call is 
suspended when the voice call is in progress). 

• Systems supporting full simultaneous voice and data active calls (with simultaneous active bearers over the air 
interface). 

The procedures for simultaneous handling of voice and data calls are for further study and will be added in future 
revisions of the present document. 

7.5.4.2.3 Using a light data service when a voice call is already established 

Initiating a light data service during established voice calls 

When a voice call (internal or external) is already established, the PP and FP may exchange C-plane messages related to 
the SUOTA service. 

If the FP does not support simultaneous voice and data calls (indicated in the « SETUP-CAPABILITY » information 
element), the PP shall not start processing any data call, as there is no guarantee that the FP will support the voice call in 
parallel with the virtual call. In other words, the PP should always wait until the end of the voice call before establishing 
a virtual call intended for any light data service. 

The procedure when the FP supports more enhanced behaviours (simultaneous voice and data calls), is left for future 
revisions of the present document. 

SUOTA push mode notifications during a voice call 

A FP implementing the SUOTA push mode procedure 7.5.6 may use an established voice call to send the generic event 
notification relating to the software upgrade indication 

7.5.4.2.4 Handling of other interactions 

Generic event notifications for telephony features while data service call is already estabUshed 

For devices supporting NG-DECT part 3 (TS 102 527-3 [17]), Generic event notifications may be sent by using any 
established call or using the CLSS procedure. The FP may use the established data call for sending the notifications. 

NOTE : if the data call is used for SUOTA and the PP is in upgrade process, the notification on PP side might be 
ignored. 

Interactions with the "Call identification" feature ([NG1.N.13] of TS 102 527-3 [17]) 

If the "Call identification" feature ([NG1.N.13] of TS 102 527-3 [17]) is implemented on FP side, call identification is 
intended for voice calls only. More specifically no call identification shall be assigned by the FP at light data service 
setup. 

7.5.4.3 Enforcement of encryption 

7.5.4.3.1 Encryption of NG-DECT part 4 data calls 

Use of encryption is mandatory in NG-DECT part 4 data transfer. Therefore all data calls shall be encrypted. The FT 
shall initiate the encryption as described in DPRS-N.17 feature. 
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7.5.4.3.2 Encryption of NG-DECT part 4 information exchange over C-plane 

Additionally the transfer of any C-plane commands related to SUOTA should be encrypted, even if they are transported 
over an existing voice call, data call, service call or over CLSS. 

• If the sending of the C-plane command is done by re-using an active link (data, voice or service call), the FT 
should initiate the encryption of the link for this call before sending the command. 

• If the sending of the C-plane command is done using the CLSS procedure, the FT should start the encryption 
before the sending of the first {FACILITY} message. 

NOTE : in terms of implementation, this may imply that any call has to be systematically encrypted or that the 
application waits until the end of a call and uses the CLSS procedure if the call was not originally 
encrypted. This may also imply that the FP starts encryption each time the CLSS procedure is used. 

7.5.5 Information exchange in tine C-Plane 

Software upgrade uses C-plane message sequences and message formats to allow FT and PT to exchange information 
about software version and availability. 

Information exchange in the C-Plane is based on the Information Element «IWU to IWU». This is used in particular 
for the exchange of version information. 

7.5.5.1 C-Plane commands general format 

The C-plane commands are based on CISS {FACILITY} messages, which contain the Information Element «IWU to 
IWU», using the dedicated protocol discriminator '06'H. 

For the purpose of transmitting the {FACILITY} message containing the « IWU to IWU » information element to 
the peer entity, the DECT entity shall either: 

• use an already established link used by any Connection Oriented service (such as a voice, data or service call), 
if existing; or 

• if there is no existing call at the time of sending the {FACILITY} message, use the CLSS procedure as defined 
in clause 10.4.2.3 of EN 300 175-5 [5]: 

If the FT is the initiator, the FP shall initiate indirect link establishment as defined in clause 7.3.8 of 
TS 102 527-1 [16] "Indirect FT initiated link establishment" procedure. The short format and the full 
format with IPUI are allowed in the paging messages. The LCE header shall be set to either; the 'OOO'B 
value (indicating "no U-plane") or to the 'lOO'B value (indicating "General code for voice service"). 

If the PT is the initiator, the PP shall initiate direct link establishment as defined in clause 8.36 of 
EN 300 444 [14] "Direct PT initiated link establishment" procedure. 

In both cases, full slot and long slot (j = 640) are allowed as slot type. The chosen slot type is decided by 
the initiating party. 

Whatever {FACILITY} transport mode is used (re-use of an already established call, or use of the CLSS procedure), 
the {FACILITY} message shall be coded with the dummy transaction identifier (TI) value 6 and the protocol 
discriminator (PD) 'OlOO'B for CISS. 
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The content of the IWU-to_IWU Information element carried in the {FACILITY} message shall be as described 
in table 18. 

Table 18: General «IWU to IWU»-based software upgrade C-plane commands format 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 










<Length of content> 


L 


Lengtii of content (1 octet) 




<S/R bit> 


1 


Transmission of message 




<Protocol Discriminator> 


06H 


Software upgrade over tlie air 




<Command > 


0...127 


Software upgrade command 




<Command specific byte 0> 
















<Command specific byte L-2> 







7.5.5.2 



Software upgrade commands 



The following software upgrade commands are defined: 
Bits 87654321 Meaning 



00000000 
00000001 
00000010 
0000001 1 



handset version indication 
handset version available 
URL indication 
negative acknowledgement 



PP => FP 


FP => PP 


YES 






YES 


YES 


YES 


YES 


YES 



All other values reserved 



7.5.5.2.1 



"Handset version indication" command 



The "Handset version indication" command allows a PP to check availability of a new software image (defined as a set 
of files, numbered from 1 to Nf, Nf < 15), and to request the urls targeting all of these files (one for each use of the 

command). 

It is sent to the FP which sends the requested file url as a response, in a "Handset version available" command 
(see clause 7.5.5.2.2). 

Decision to send a "Handset version indication" command shall be taken by the PP according to the provisions of 
clause 7.6.2.2.1, "Step 1-PP sends a "Handset version indication" command to the FP. The PP shall not queue several 
"Handset version indication" commands. 

The URL following this command (see octet 7), if present, shall contain a valid URLl value to be used in step 2 
(see clause 7.6.2.2.2, "Step 2-FP retrieves url of the next file to be downloaded (FP_URL2)"). 
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Bit: 



IWU-TO-IWU 



0/1 ext 



Length of Contents (L = Ls + Lh + 11 ) 



S/R = 1 



Protocol Discriminator = "Software upgrade over 
tlie air" = '06'H 



Command = "hHandset version indication" = 'O'H 



ElVIC value high byte 



EMC value low byte 



URL1 to follow 







0/1 ext 



reserved 



flags 



fileNumber 



reason 



cSW Version identifier> = 1 



Length of SW Version identifier (1 < Ls < 20) 



SW Version identifier first octet (IA5 character) 



SW Version identifier last octet (IA5 character) 



<HW Version identifier> = 2 



Length of HW Version identifier (1 < Lh < 20) 



HW Version identifier first octet {IA5 character) 



HW Version identifier last octet (IA5 character) 



Octet: 

1 
2 
3 

4 

5 

6 

7 

8 
8a 

9 

10 
11 

Ls+10 
Ls+11 
Ls+12 
Ls+13 

Ls+Lh+12 



Figure 7: «IWU-TO-IWU» information element 
for the "Handset version indication" command 

Equipment Manufacturer's Code (EMC) 

Equipment Manufacturer's Code 16-bit value, as defined in EN 300 175-6 [6]. 
URLl to follow (URLl_to_follow) (octet 7) 

Bits 87654321 Meaning 

00000000 URL does not follow 
00000001 

to Number of URL messages following in a "URL indication" command 

11111111 

If present, URLl value shall follow in one or several "URL indication" commands (see clause 7.5.5.2.3). 

File number field (fileNumber = "n") (octet 8) 

Interpretation of the fileNumber field depends on the reason field value. 

If the reason field is "0", fileNumber is the ordinal number of the requested file. This implies that files with 
number between 1 and fileNumber- 1 where applied successfully. 

If the reason field is not "0", the "fileNumber" field refers to the file number of the file whose application 
failed. 

Reason field (reason) (octet 8a) 

The interpretation of the "Handset version indication" command depends on the reason field value: 

when the "reason" field is "0", the command is a request for a new file, as described in clause 7.6.2.2. 1. 

when the "reason" field is non zero, the command is a notification of failure, as described in clause 7.6.2.6. 

NOTE 1: The meaning of the "fileNumber" field also depends on the "reason" field value. See "File number field" 
description. 
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Bits 4 3 21 Meaning 

Success of previous files application. Request for a new file (indicated by "fileNumber" field) 

1 Download of file with indicated fileNumber failed 

10 Application of file with indicated fileNumber failed 

11 Unable to download in time-New DelayMinutes requested (see clause 7.5.5.2.2, DelayMinutes 

field for details) 
All other values reserved. 

NOTE 2: Application of a file refers to the intended use of the file during installation of the new software, and until 
the next file is requested. 

Flags (octet 8a) 

Bits 7 6 5 Meaning 

X X 1 User initiated software upgrade 

Bits 6 and 7 are reserved for further standardization. They shall be set to "0". 

SW Version identifier (octet 9) 

A field identifier value of "1" shall be used in octet 9. PP current software version identifier. The length of this 
parameter shall be of 20 octets maximum. Only IA5 characters shall be used. 

The SW version identifier value is software provider specific, and shall be defined by the PP vendor. It shall not be 
empty. The value used shall represent the currently installed version of the software, not the targeted S W version 
identifier (although it is known from the first response of the FP on). 

The field value shall be set to a value allowing the MS to determine the software identity and version to be downloaded 
(not only the version, unless the software identity is implicit). Examples of field values: 

SW Version identifier ="FIRMWARE-1.2.0". 

SW Version identifier =" WEATHER- WIDGET-1 .2.0". 

SW Version identifier ="1.2.0". 

NOTE 3: The FP should not interpret this value and should always rely on the management server response to get 
the new software version identifier documented in the "Handset version available" command. 

NOTE 4: In case the SUOTA feature is used for a software first installation (i.e. not for an "upgrade"), a special 
value of the field should be defined to indicate this (i.e. the initial software version identifier cannot be 
used as it is not the currently installed version). 

HW Version identifier (octet Lh+ 11): 

A field identifier value of "2" shall be used in octet Lh + 1 1 . PP hardware version identifier. The length of this 
parameter shall be of 20 octets maximum. Only IA5 characters shall be used. 

This value does not change during the whole lifecycle of the PP. 
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PT 



FT 



Following a Software Upgrade triggering event 



FACILITY 



« IWU-to-IWU handset version indication, EMC, software version, 
hardware version, URL to follow=2 » 



FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, URL content part 1 » 



FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, URL content part 2 » 

Figure 8: "Handset Version indication" procedure 

NOTE 5: "URL indication" command is described in clause 7.5.5.2.3. 

A handset software version is clearly identified by the parameters EMC, SW Version identifier, and HW Version 
identifier, which can be used by the management server to assign a new software image. 



7.5.5.2.2 



"Handset version available" command 



Bit: 



Octet: 



« IWU-TO-IWU » 



Length of Contents (L = Ls + 8) 



0/1 ext 



S/R = 1 



Protocol Discriminator = "Software upgrade over 
the air" = '06'H 



Command = "Handset version available" = '1'H 



DelayMinutes value high byte 



DelayMinutes value low byte 



URL2 to follow 



0/1 ext 



User interaction 



reserved 



<SW Version identifier> = 1 



Length of SW Version identifier (0 < Ls < 20) 



SW Version identifier first octet (IA5 character) 



SW Version Identifier last octet (IA5 character) 



1 
2 
3 

4 

5 

6 

7 

8 

9 

10 
11 

Ls+10 



Figure 9: «IWU-TO-IWU» information element 
for the "l-iandset version available" command 

Delay for download in minutes (DelayMinutes) (octets 5 and 6) 

Delay in minutes, starting from current time (i.e. from reception of the "Handset version available" command), to be 
respected by the PP until the actual software image download can start. 
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This delay allows the MS: 

to avoid server overload by distributing downloads over time; 

to minimize user disturbance, by differing downloads until the next night; 

to schedule distinct software upgrades to the same PP (each with its own set of files). 

A value of "0" indicates that an immediate download is required by the MS. 

A value of "FFFF"H indicates that the delay is undefined (the PP may attempt a download at any time). 

First file download: The delay is especially significant for the first file (when fileNumber = "1" in the PP request). The 
PP shall respect the indicated delay as a lower bound and shall try to immediately download the software after the delay 
has timed out. 

More specifically, the download of the first file shall start as soon as possible after CurrentTimeMinutes + 
DelayMinutes, where CurrentTimeMinutes refers to the reception time in minutes of the request (from any time origin). 

Next files download: For the next files (fileNumber > 2), and provided the PP does not ask for a new delay (see 
below), the FP shall set the DelayMinutes parameter to "0", so that the overall upgrade time will be as short as possible. 

Possible request for a new delay: If the PP cannot respect the delay for a file (the first file, or any file), e.g. if the PP 
was switched off or the server was unreachable when the delay timed out, the behaviour of the PP is left up to the PP 
vendor. For example: 

• the PP may try to download the software anytime afterwards; 

• or, the PP may respect a build-in download window. More specifically in that case: 

the PP will not try to download the current file after CurrentTimeMinutes + DelayMinutes + 
DownloadWindowMinutes, where DownloadWindowMinutes represents the built-in download window 
length for downloading; 

additionally, if the download window cannot be respected, the PP asks for a new DelayMinutes value 
(hence a new download window), using the "reason" field value of "Unable to download in time-New 
DelayMinutes requested" (see clause 7.5.5.2.1), in order to be able to download the remaining (or all) 
files. 

NOTE: In case of firmware upgrade, a PP may request a new download window while keeping some already 
downloaded files in the following cases: 

because it has sufficient memory to keep them while still being functional; 

or because it can no longer revert to a working version (but only a rescue version only allowing 
firmware upgrade). 

URL2 to follow (URL2_to_follow) (octet 7) 

Bits 87654321 Meaning 

00000000 URL does not follow 
00000001 

to Number of URL messages following in a "URL indication" command 

11111111 

If present, URL2 value shall follow in one or serveral "URL indication" commands (see clause 7.5.5.2.3). 
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User interaction (octet 8) 

Bits 7 6 5 Meaning 

No user interaction required 

1 User interaction required 

10 User interaction undefined 

All other values reserved. 

This field allows the MS to indicate wheter a user interaction is required or not before the actual download of the 
software can take place. Value 'OlO'B indicates that there is no MS requirement concerning user interaction. 

SW Version identifier (octet 9) 

A field identifier value of '1 ' shall be used. Software version identifier of the software to be installed as a result of the 
upgrade (not the currently installed version). The length of this parameter shall be of 20 octets maximum. Only 1A5 
characters shall be used. 

If a new software version is available, this field shall not be empty (the length shall not be '0') in order to allow future 
upgrades. An empty "software version identifier" (length = 0) shall be used if there is no new version available. 

The SW version identifier value is software provider specific, and shall be agreed with the MS operator. 



PI 



FT 



once a new SW version is available 



Facility 



« IWU-to-IWU handset version available, software version, DelayMinutes, 
URL to follow=2» 

Facility 



« IWU-to-IWU URL indication, URL to follow=1 , URL content part 1 » 



Facility 



« IWU-to-IWU URL indication, URL to follow=0, URL content part 2 » 



Figure 10: "Handset Version available" procedure 

NOTE: "URL indication" command is described in clause 7.6.2.4.2.3. 
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7.5.5.2.3 



"URL indication" command 



Bit: 



Octet: 



IWU-TO-IWU 



0/1 ext 



S/R= 1 



Length of Contents (L = Lu + 8) 



Protocol Discriminator = "Software upgrade over 
the air" = '06'H 



Command = "URL indication" = '2'H 



URL to follow 



Length of URL content in this IE (Lu) 



URL content first octet (IA5 character) 



URL content last octet (IA5 character) 



1 
2 
3 

4 
5 
6 

7 

Lu + 6 



Figure 11: «IWU-TO-IWU» information element 
for the "URL indication" command 

URL to follow (URL_to_follow) (octet 5) 

Bits 87654321 Meaning 

00000000 This message is the last message and contains the last part of the URL 
00000001 

to Number of remaining "URL indication" messages following this message 

11111111 



7.5.5.2.4 



"Negative acknowledgement" command 



The "negative acknowledgment" command is used by the FP or the PP for notifying errors arising during the use of 
C-plane software upgrade commands. 

NOTE 1: The allowed directions of use depend on the "Reject reason" field value. 

It shall not be used to notify errors arising from the use of "Binary content download" feature over the U-plane, when 
downloading the software image. 

Table 19: Values used within «IWU to IWU» information element 
for the "negative acknowledgement" command 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU to IWU» 










<Length of content> 


LH 


Length of content 




<Protocol Discriminator> 


06H 


Software upgrade 




<Command=negative 

acknowledgement > 


03H 


Software upgrade command 




<Reject reason> 


0...255 


Reject Reason 



Reject reason 
Bits 87654321 



Meaning 



Direction 



00000000 Reserved both 

1 Retry later - Connection refused (see note 2) FP to PP 

00000010 Retry later - FP resources overflow (see note 2) FP to PP 

1 1 File does not exist (see clause 7.6.2.2.3, option 3) FP to PP 

10 Invahd URLl format FP to PP 

10 1 Unreachable URLl (server error) FP to PP 

000001 10 Command format error both 



all other values reserved. 
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NOTE 2: The "Retry later" error code may be used in case the FP is faced with several simultaneous upgrade 
requests (using the "handset version indication" command) from several PPs, which it cannot handle 
simultaneously. 

The "Retry later - Connection refused" value shall be used in case an additional connection cannot be setup by the FP 
with this PP. 

The "Retry later - FP resources overflow" value shall be used in case the PP connection was accepted but the remaining 
hardware resources are not sufficient to handle the upgrade. 

7.5.6 SUOTA push mode 

A FP implementing the present procedure shall use the "generic event notification" procedure of TS 102 527-3 [17], 
clause 7.4.1, to forward software upgrade indications to the PP. 

The «CALL-INF0RMAT10N» information element shall not be sent as part of this notification. 

For indication of values used in «Events notification» information element, see table 20. 

Table 20: Values used within {FACILITY} message for software upgrade indication 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«Events notification» 


<Event type> 


4 


Software upgrade indication 


<Event sub type> 


Oor1 


Unknown 

1 Firmware upgrade 


<Event multiplicity > 





Not used. Shall have a value of "0" 



A PP implementing the present procedure should attempt a Software upgrade Over The Air (see clause 7.6.2) when 
receiving the notification. However, the PP exact behaviour is left up to the PP vendor. More specifically, a "Handset 
Version Indication" command could be sent anytime afterwards, or not be sent at all. 

EXAMPLE 1: A PP could respect a built-in timeout, and send a "Handset Version Indication" command as 

described in clause 7.6.2.2. 1 only if it has the opportunity to do so within this timeout, and ignore 
the notification otherwise. 

EXAMPLE 2: A PP could respect a delay between the sending of two consecutive "Handset Version Indication" 
commands for security reasons, forcing it not to respect the built-in timeout. 

EXAMPLE 3: A PP could ignore notifications transferred from a FP from a different vendor, from a blacklisted 
FP, etc. 



7.5.7 Terminal capability indication 



The contents of the <Terminal Capability> information elements shall be based on the requirements of 
EN 301 649 [15], clause 12.3. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [15] shall apply. 
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Table 21 : Values used within the «TERMINAL CAPABILITY» information element 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«Terminal capability» 










<ext4> 









<Profile indicator 1> 


'x 1 X X X X x'B 


OUT OF SCOPE (DPRS Stream support) 






'1 xxxxxx'B 


OPTIONAL (Asymmetric bearer) 




<ext4a> 









<Profile indicator_2> 


'xxxxxx 1'B 


OPTIONAL(DPRS Class 2 management 
and B-field procedures (DPRS-M.5) 
supported (EN 301 649 [15]) 




<ext4b> 









<Profile indicator 3> 


'x 1 X X X X x'B 


OUT OF SCOPE (Ethernet support) 






'1 X X x x x x'B 


OUT OF SCOPE (Tol<en Ring support) 




<ext4c> 









<Profile indicator 4> 


'xxxxxx 1'B 


OUT OF SCOPE (IP support) 






'x X X X x 1 x'B 


OUT OF SCOPE (PPP support) 






'x X X X 1 X x'B 


OUT OF SCOPE (V.24 support) 






'x X X 1 x x x'B 


OPTIONAL (Cp supported) 






'x X 1 x x x x'B 


OPTIONAL (IpQ services supported) 






'1 X X xxx x'B 


MANDATORY (Generic Media 
Encapsulation supported) 




< ext4d > 









< ext4e > 











'x X 1 x x x x'B 


OPTIONAL (Channel Gp supported, see 
note 2) 






'x 1 X X X X x'B 


OPTIONAL (PT with fast hopping radio) 






'1 X X x x x x'B 


OPTIONAL (Capability to support "no 
emission" mode (see EN 300 175-3 [3], 
clause 9.4) 




< ext4f > 









< ext4g > 











'x X x X X X 1 'B 


OPTIONAL (E+U-type mux and channel 
Ipp basic procedures supported, 

see note 1) 






'x X X X x 1 x'B 


OPTIONAL (Channel Ipp advanced 
procedures supported) 






'x X X X 1 X x'B 


OUT OF SCOPE (Channel SIpp 
supported) 




<Pacl<et data category> 


any 


OUT OF SCOPE of the present 
document. System may be categorized 
due to other data capabilities. If not 
categorized, code shall be set as 0. 




< ext4h > 


1 








'x X X X X X 1 'B 


OPTIONAL (DPRS Class 3 management 
and A-field procedures (DPRS-M.30) 
supported (see EN 301 649 [15],) 






'x X X X x 1 x'B 


MANDATORY (DPRS Class 4 
management and A-field procedures 
(DPRS-M.30) supported (see 
EN 301 649(15]) 






'x 1 X X X X x'B 


MANDATORY (Support of Light data 
services (the present document) 


NOTE 1 : IF DPRS-M.23 THEN MANDATORY ELSE OPTIONAL. 
NOTE 2: IF DPRS-M.19 THEN MANDATORY ELSE OPTIONAL. 
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7.5.8 Call resources/parameters negotiation 

The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [15], 
clause 12.5, with the fields and values listed in table 22. 

Table 22: Values used within the {CC-SETUP} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« IWU attributes » 










< Length of Contents > 


any 






< Coding standard > 


01 


Profile defined coding. 




< Profile > 


00000 


DPRS Frame Relay support 
(MANDATORY) 




< Negotiation Indicator > 


000, 
010 


- Negotiation not possible (see note 1). 

- Peer attribute negotiation. 




< Profile Subtype > 
(octet 4) 


1 000 


DECT Generic media encapsulation 
(IVIANDATORY, Other options Out of 
scope) 




<IVIaximum SDU size> PI 
=> FT (octets 5 and 5a) 


> 191 (equivalent to 1 
528 octets) 


At least 1 528 octets (codec as 191) shall 
be supported (see note 7) 




<Maximum SDU size> FT 
=> PT (octets 5b and 5c) 


> 1 528 (equivalent to 
12 224 octets) 


At least 12 224 octets (codec as 1 528) 
shall be supported (see note 7) 




< Profile Subtype 
attributes> (octet 6) 


several values and 

number of octets 

possible 


See DPRS [15], clauses B.2 and B.8 


« Call attributes » 










< Coding standard > 


00 






< NWK layer attributes > 


00010,00011,00110 


DPRS Class 2, DPRS Class 3, DPRS 
Class 4. Only values for implemented IVIE 
Classes need to be supported. 




< C-plane class > 


010 


Class A shared is only mandatory, rest 
are optional and need not be supported 
by the peer side. 




< C-plane routing > 


0000, 
0100 


Cg only; 
Cponly; 
Support of Cp is optional. 




< ext5 > 


1 






< U-plane symmetry > 


00 


Symmetric (see note 6). 




< LU identification > 


01010 


LU10. 




< exte > 


1 






< U-plane class > 


101 


Class 2; SELective. 




< U-plane frame type > 


1010 


FU1 Oa/c mandatory for support. 










« Connection 
attributes » 






Signifies the maximum capabilities of the 
sender for the requested call. If not 
included the default value shall be 
assumed (see clause 12.5.1 of [15]). 




< Symmetry > 


001 
010 
101 


Symmetric only connection 
Asymmetric reversible 
Asymmetric one-way-only 

Asymmetric types are applicable only 
when operating in ME Class 2 and B-field 
signalling (DPRS-M.5). 




< Connection identity > 


0000 


Not yet numbered. 




ext4 


0,1 


If 1 is indicated, the octets 4a, 4b and 4c 
shall not be included and their values 
shall be understood to be equal to the 
value set in < Target bearers 
(P = > F direction) >. 




< IVIaximum bearers 
(P = > F direction) > 


OOnnnnn 
nnnnn = 1 to 23 


If "Symmetric" has been indicated max. 
value that needs to be supported is 12. 
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Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 




ext4a 


0,1 


If 1 is indicated, the octets 4b and 4c shall 
not be included and their values shall be 
understood to be equal to the values set 
in octets 4 and 4a respectively. 




< Minimum bearers 
(P = > F direction) > 


Oinnnnn 
nnnnn = to 23 






ext4b 


0, 1 


If 1 is indicated, the octets 4c shall not be 
included and its value shall be 
understood to be equal to the value set in 
octet 4b. 




< l\/laximum bearers 
(F = > P direction) > 


lOnnnnn 
nnnnn = 1 to 23 






ext4c 


1 






< IVIinimum bearers 
(F = > P direction) > 


11 nnnnn 
nnnnn = Oto 23 






< ext5 > 


0, 1 


If 1 is indicated, octet 5a shall not be 
included and its value shall be 
understood to be equal to the value set in 
octet 5. 




< MAC slot size > 


001 
100 
101 


long slot 640 MANDATORY to support 
full slot Optional to support 
double slot Optional to support 












< MAC service P = > F > 


0010 
0011 
0110 
0111 


Ipiy,; detect: MANDATORY to support 

Ipiyip; Mod-2 correct: Optional 

IpQ; detect: optional 

IpQp; Mod-2 correct: Optional 

Support of "Ip; Mod-2 correct" and IpQ is 

optional 




< extSa > 


1 






< spare > 


000 






< MAC service F = > P > 


0010 
0011 
0110 
0111 


Ipiy,; detect: MANDATORY to support 

Ipiyip; Mod-2 correct: Optional 

IpQ; detect: optional 

IpQp; Mod-2 correct: Optional 

Support of "Ip; Mod-2 correct" and IpQ is 

optional 




< Ext6 > 


1,0 


If 1 is indicated, octet 6a shall not be 
included and its value shall be 
understood to be equal to the value set In 
octet 6. 




< Cp cliannel attributes 
P = >F> 


000, 
010,011, 100, 101 


Cp never (Cg only) 

Cp priorities A, B, C or D 

Support of Cp is optional. 




< MAC pacl<et life time 
P = >F> 


oto 7 


Values > only for lp_error_correct. 




< Ext6a > 


1 






< Cp cliannel attributes 
F = >P> 


000, 
010,011, 100, 101 


Cp never (Cg only) 

Cp priorities A, B, C or D 

Support of Cp is optional. 




< MAC packet life time 
F = >P> 


oto 7 


Values > only for lp_error_correct or 
lpQ_error_correct. 




< Ext7 > 


1 


See note 5. 




< A-attributes > 


000 


2-level modulation scheme 




< B-attributes > 


000, 
001, 
010 


2-level modulation scheme 

4-level modulation scheme 

8-level modulation scheme 

The support of 4 and 8 level modulation 

scheme is optional. 
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Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« Transit delay » 






For the default value in case it is not 
included see clause 12.5.1 of [15]. 




< Forward Delay > 



All 


Infinite - Mandatory for support 
Rest - optional. 




< Backward Delay > 



All 


It is not required to support different 
values in Backwards direction. 


« Window size » 






(See note 2) 

For the default values if not included 

see clause 12.5.1 of [15]. 




ext3 









< Window size value 
(forward) > 


All 


The value shall be placed in both 3 and 
3a octets as defined in EN 300 175-5 [5], 
clause 7.7.43 (for the range of allowed 
values see clause 11.1.1 of [15]). 
Maximum allowed for this profile 
value = 256. 
(see note 3) 




ext3a 


1 






< Window size value 
(forward) continue > 


All 






ext4 









< Window size value 
(backward) > 


All 


The value shall be placed in both 3 and 
3a octets as defined in EN 300 175-5 [5], 
clause 7.7.43 (for the range of allowed 
values see clause 11.1.1 of [15]). 
Maximum allowed for this profile 
value = 256. 




ext4a 


1 






< Window size value 
(backward) continue > 


All 




NOTE 1 : This value may only be used if all other parameters have values equal to the default values 

(see clause 12.5.1 of [15]). 
NOTE 2: If octet group 4 (i.e. 4, 4a, 4b) is omitted the values defined in Octet group 3 apply for both directions. 
NOTE 3: The values introduced in clause 11.1.1 of [1 5] need to be respected in all window-size fields. 
NOTE 4: The direction of the connection downlink (FT-to-PT) or up-link (PT-to-FT) will be dynamically negotiated at 

IVIAC layer. 
NOTE 5: For backwards compatibility, if octet 7 is not included support of 2-level modulation scheme for both 

A- and B-field shall be assumed. 
NOTE 6: If "Symmetric" is indicated octets 4b, 4c, 5a and 6a need not to be included. 
NOTE 7: Value 191 (equivalent to 1 528 octets) is codec as '0000001 'B in octet 5 and '01 1 1 1 1 1 'B in octet 5a. 



7.5.9 IWU-attributes change 



The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [15], 
clause 12.7. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [15] shall apply. 
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Table 23: Values used within the {CC-SERVICE-CHANGE} message 



Information element 


Field within the 
information element 


Standard values 

within the 

field/information 

element 


Normative action/comment 


«IWU attributes» 










<Profile> 


00001 


OUT OF SCOPE (Stream support) 






00000 


MANDATORY (FREL support) 




<Profile Subtype> 


0000 


OUT OF SCOPE (IEEE 802.3 [i.8] / 
Ethernet (WLAN)) 






1000 


OUT OF SCOPE (Interworking to V.24 
circuits (RS232) 






0001 


OUT OF SCOPE (IEEE 802.5 [i.9], 
(clause B.5)) 






0010 


OUT OF SCOPE (Internet Protocol 
(IP) (clause B.6 (RFC 791 [19])) 






0100 


OUT OF SCOPE (Point-to-Point 

Protocol 

(clause B.7 (RFC 1661 [i.10])) 






1000 


MANDATORY (Generic Media 
Encapsulation Protocol (clause B.8)) 



7.5.10 Broadcast attributes management 

The contents of the messages applicable to this procedure shall be based on the requirements of the EN 301 649 [15], 
clause 12.16. 

For the purpose of this ASAP only the status of the fields and specific values implementation that has changed is 
indicated in this clause. For the rest whatever specified in EN 301 649 [15], shall apply. 

Table 24: Extended higher layer capabilities interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


a27 


Generic Media 
Encapsulation 


1 


MANDATORY 


a29 


Ethernet 


X 


OUT OF SCOPE 


aSO 


Token Ring 


X 


OUT OF SCOPE 


a31 


IP 


X 


OUT OF SCOPE 


a32 


PPP 


X 


OUT OF SCOPE 


a33 


V.24 


X 


OUT OF SCOPE 


a45 


DPRS Class 3 or Class 4 
management and A-field 
procedures supported 
(DPRS-M.30), 


1 


MANDATORY (see note) 


a46 


DPRS Class 2 management 
and B-field procedures 
supported (DPRS-M.5) 


0,1 


OPTIONAL (IF DPRS-ME.2 THEN "1" ELSE "0"). 


NOTE: The supported management Class is inferred from the state of bit a21 (MAC suspend/resume supported). If 
bit a21 = 1 then Class 3, if a21 is = 0, then Class 4. 



Table 25: Extended higher layer capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


< a25 - a28 > 


NG-DECT Packet Data 
Category 


any 


Irrelevant for the present specification. System may 
be categorized due to other data capabilities 


a35 


no-emission mode support 


0,1 


OPTIONAL 


a45 


Light data services 

(TS 102 527-4) supported 


1 


MANDATORY 
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7.6 Application layer procedures 



The procedures as specified in EN 301 649 [15], clause 12 shall apply with the modifications and additional procedures 
listed in the present clause. 



7.6.1 Binary content download 



7.6.1.1 



Binary content download general requirements 



The "Binary content download" feature allows the design of "PP to server" distributed applications (see the definition 
below), based on HTTP, and usable with any Part 4 FP. 

NOTE 1 : "Binary" refers to DECT layers transparency toward the type of files being transmitted to the PP. 

Distributed application. A distributed application is an application available to the user on a DECT handset, for which 
part of the code (behaviour) and/or data is located on the handset (local tier) and part of it is located in the network 
(remote tier). The remote tier may consist in one or more HTTP servers. 

There is a strong relationship between the local and remote tiers of the application, so that the PP and servers are 
assumed to be designed in a compatible manner. 

NOTE 2: This feature may be used with several possible design structures: HTTP servers hosted by the PP 
manufacturer, or PP vendor, or other parties. 

For interoperability reasons, the remote tier of a pure binary content download application should not be hosted on 
the FP. 



PP 



application 
(local tier) 



Full interaction possible 

4- 



APIs 



Middleware 



Operating 
system 



DECTNWK 
and stack 



(DPRS Over the Air) 

HTTP 1.1 based 
requests 



C plane interactions 

K -y\ 



FP 



■> <- 



DECT NWK 
and stack 



HTTP 1.1 requests 
forwarded 



HTTP 
server 



Application 

(remote 

tier) 



Figure 12: Distributed application using "Binary content download" 

7.6.1 .2 LU1 interworking conventions and HTTP profile 

7.6.1 .2.1 LU1 interworking conventions and HTTP profile for "Simple binary content 

download" 

For the "Simple binary content download" procedure, a file transfer shall occur in the U-Plane based on a single context 
of HTTP protocol, transported over DPRS Generic Interworking Encapsulation Protocol (DPRS [15], clause B.8). 
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The following specific provisions related to Generic Media Encapsulation shall apply: 

• HTTP hmited set nr. 2 as described in DPRS (EN 301 649) [15], clause B.8.3.4 shall be used. 

• HTTP limited set nr. 2 includes: 

support by both the PP and FP of the HTTP partial GET method (see note); 

support by the PP of the media type "application/octet-stream" at least; 

support of a limited set of HTTP headers. 

NOTE: A partial GET is characterized by the presence of a "Range" header in an HTTP GET request. Presence of 
this header is mandatory for all GET requests between the PP and the FP (as described in the "Common 
HTTP profile"), even if a whole resource is requested. 

• HTTP hmited set nr. 3 as described in DPRS (EN 301 649) [15], clause B. 8.3.5 may optionally be used. 

• Protocol identifier code 1079 (or 1077 if hmited set nr. 3) shall be used or assumed in IE «IWU-Attributes» 
control octets. 

• Basic services "light data service with Class 4 DPRS management" (code 'lOOl'B) OR "light data service with 
Class 3 DPRS management" (code 'lOlO'B) shall be used. 

• The simplified single-context Interworking procedure described in DPRS [15], clause B.8.4.3 shall be used. 

7.6.1 .2.2 LU1 interworking conventions and HTTP profile for "Enhanced binary content 

download" 

For the "Enhanced binary content download" procedure, a file transfer shall occur in the U-Plane based on one or 
several contexts of HTTP protocol, transported over DPRS Generic Interworking Encapsulation Protocol 
(DPRS [15], clause B.8). 

The following specific provisions related to Generic Media Encapsulation shall apply: 

• HTTP hmited set nr. 2 as described in DPRS (EN 301 649) [15], clause B.8.3.4 shall be used. 

• HTTP hmited set nr. 3 as described in DPRS (EN 301 649) [15], clause B. 8.3.5 may optionally be used. 

• HTTP limited set nr. 2 includes: 

support by both the PP and FP of the HTTP partial GET method (see note). 

support by the PP of the media type "application/octet-stream" at least. 

support of a limited set of HTTP headers. 

NOTE: A partial GET is characterized by the presence of a "Range" header in an HTTP GET request. Presence of 
this header is mandatory for all GET requests between the PP and the FP (as described in the "Common 
HTTP profile"), even if a whole resource is requested. 

• Protocol identifier code 1079 shall be used or assumed in IE «IWU-Attributes» control octets. Protocol 
code 1077 may be used. 

Basic services "light data service with Class 4 DPRS management" (code 'lOOl'B) OR "light data service with Class 
3 DPRS management" (code 'lOlO'B) shall be used. 

• The multi-context Interworking to an application proxy procedure described in DPRS [15], clause B.8. 4.2 shall 
be used. 

• The feature DPRS-N.35 (Service change) shall be supported. 
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7.6.1 .2.3 LU1 interworking conventions and HTTP profile for "Generic multiprotocol binary 

content download" 

For the "Generic multiprotocol binary content download" procedure, a file transfer shall occur in the U-Plane based on 
one or several contexts of HTTP protocol, transported over DPRS Generic Interworking Encapsulation Protocol 
(DPRS [15], clause B.8). 

The following specific provisions related to Generic Media Encapsulation shall apply: 

• All implementations shall support at least the following protocols: 

HTTP limited set nr 2.as described in DPRS (EN 301 649) [15], clause B. 8.3.4 (protocol code 1079). 

Full HTTP as RFC 2616 [22] (protocol code 80). 

DNS as RFC 1034 [25] and RFC 1035 [26] (protocol code 53). 

Any other protocol transportable over TCP or UDP may be also supported.. The HTTP limited set nr 1 as 
described in DPRS (EN 301 649) [15], clause B.8. 3.3 (protocol code 1078) and the HTTP Hmited set 
nr.3 as described in DPRS (EN 301 649) [15], clause B.8. 3.5 (protocol code 1077) may also be 
supported. 

• The proper protocol identifier codes according to the rules of DPRS [15], clause B.3.1 shall be used. 

• Basic services "light data service with Class 4 DPRS management" (code TOOl'B) OR "light data service with 
Class 3 DPRS management" (code 'lOlO'B) maybe used; It is also allowed to use DPRS-N.34 (Service 
negotiation at call setup). 

• It is allowed to use DPRS-ME.2, DPRS-ME.3 or DPRS-ME.4. IF DPRS-ME.2 THEN feature DPRS-N.34 is 
mandatory. 

• Feature DPRS-N.33 (Dynamic parameters allocation) shall be supported, at least for the Application indicator 
and capability octets in «Setup capability». IF DPRS-ME.2 then feature DPRS-N.33 shall be supported in 
full. 

• The Generic Multiprotocol Interworking to external IP networks described in DPRS [15], clause B. 8.4.1 shall 
be used. 

• The feature DPRS -N. 35 (Service change) shall be supported. 

7.6.1 .3 Binary content download media type 

For the "Binary content download" feature, the client shall support at least media type "application/octet-stream", as 
specified in clause A. 1.5. 

NOTE: In the context of the HTTP protocol, media types are used in the "Accept" (from client) and "Content- 
Type" (from server) header fields. Media types allow content type negotiation and content type 
notification. 

7.6.1 .4 Binary content download sequence 

The binary content download feature shall use the following sequence of messages. 
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PP 



FP 



Data channel establishment 



CC-SETUP 



« Basic-Service <Call class = 'Normal call setup' = 8H>, 

<Basic service = 'Binary Content Download' = 9H>, 



CC-CONNECT 



HTTP limited set (according to DPRS B. 8.3.4) 



Data channel release 



CC-RELEASE 



CC-RELEASE-COI\/l 



Content 

server 

(local in FP 

or remote) 



see NOTE 



NOTE: FP to content server data exchange is out of scope of the "Binary content download" feature description. 
This data exchange may or may not involve HTTP. 

Figure 13: DECT connection for "Binary content download" 

File downloading resumption. Thanks to the use of partial GETs ("Range" header mechanism), the PP can download a 
file in several steps, either by using several GET messages within the same connection, and/or by using several 
connections (e.g. following a connection break down). 

7.6.1 .5 URI-based PP to FP security requirements 

The following two procedures allow the PP to require the FP to use one or several security features with the server 
when retrieving an HTTP resource over the network. 

NOTE 1: These procedures use the Request URI and therefore extend clause A. 1.3, "Request URI and Host header 
field" of the "Common HTTP profile". 

NOTE 2: Both types of security requirements (respectively defined in clauses 7.6.1.5.1 and 7.6.1.5.2) may be 
combined in a single URI. 

NOTE 3: Use of the following two procedures, together with an extension of their use with URLs sent via the 
C-plane, is illustrated in clause B.3 in the case of SUOTA. See also clause 7.6.2.4. 

In case the FP does not implement the required security feature, the FP shall send the status code "700 Unimplemented 
security feature". 



7.6.1.5.1 



URI-based PP to FP confidentiality requirement 



The "URI-based PP confidentiality requirement" procedure allows the PP to request the FP to use confidentiality when 
retrieving an HTTP resource over the network. 

NOTE 1 : A security requirement for confidentiality is not intended to protect PP to FP exchange of data, which are 
protected by DECT specific means. 
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A PP implementing the present procedure: 



shall be able to send to the FP a URI with "https" scheme value, as in: 
GET https://suota.example.com/path/file.bin HTTPl.l; 

shall be prepared to receive a status code "700 Unimplemented security feature" as a response to the request. 

A FP implementing the present procedure: 

shall implement HTTPS ; 

shall interpret the presence of the "https" scheme value as a requirement for using HTTPS with the 
corresponding server for ensuring the confidentiality of the exchange, and shall fulfil this requirement. 

NOTE 2: HTTPS relies on a SSL/TLS layer between HTTP and TCP. 

NOTE 3: Encryption only relies on the server encryption private and public keys, and corresponding certificate (the 
FP does not need to own any encryption key). The FP should implement a TLS/SSL stack and 
embed/trust the public key of the server certificate authority, or of one of its ancestors. 

7.6.1 .5.2 URI-based PP to FP authentication requirement 

The "URI-based PP authentication requirement" procedure allows the PP to request the FP to use a client authentication 
scheme on behalf of the PP when retrieving an HTTP resource over the network. 

A PP implementing the present procedure: 

• shall be able to send to the FP a URI with authority part containing a userinfo element of the form 
"username:password@", as in the following example: 

EXAMPLE: GET http://ppl :mypassword@suota. example.com/path/file.bin HTTPl.l. 

• shall be prepared to receive a status code "700 Unimplemented security feature" as a response to the request. 
A FP implementing the present procedure: 

• shall implement HTTP-based "basic" and "digest" authentication. 

• shall interpret the presence of a "userinfo" element within the "authority" part of the URI as a requirement for 
using HTTP-based "basic" or "digest" authentication (as requested by the server) with the corresponding server 
for ensuring the authentication of the PP, and shall fulfil this requirement. 

NOTE: For PP authentication to work this way, the PP should entrust the FP with its own authentication 
password, and therefore should trust the FP. 

7.6.1 .6 PP to FP enhanced interactivity 

The "PP to FP enhanced interactivity" procedure allows the PP to send HTTP requests with data (most notably 
"completed forms") to the FP (and beyond). It allows to create enhanced "Binary content download" based applications. 

NOTE 1: This procedure is not used by the "Software upgrade over the air" feature, which relies on the C-plane for 
the same purpose. 

A PP compliant with the present procedure shall implement the "Extended HTTP profile" of clause A.2. 

NOTE 2: Distributed applications with a PP embedded local tier may exist that do not make use of the enhanced 

interactivity provided by the present procedure-only relying on URLs for PP to FP (limited) interactivity. 
However, URL-based interactivity (such as parameters sending) is inefficient for large amounts of data 
and does not provide a standard way of handling character encodings. 

A PP compliant with the present procedure shall be able to send POST requests using the "multipart/form-data" format 
as described in clause A.2 (and especially upon request of the server, e.g. using "encType" attribute if XHTML <form> 
tags are supported). 
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A FP compliant with the present procedure shall be prepared to receive POST requests as described in clause A.2 and to 
forward them to the content download application remote tier. 

7.6.2 Software upgrade over the air (SUOTA) 
7.6.2.1 SUOTA general requirements 

7.6.2.1.1 Definitions 

Software package: A set of files sharing the same version identifier, and needed by the PP for installing or upgrading 
an application or a firmware. The software package is often simply referred to as the "software". 

Software version identifier: This parameter identifies a software package, including the software package version. 
From PP to FP, this parameter identifies the currently installed software package. From FP to PP it identifies the 
software package to be installed as a result of the upgrade (and is shared by all the files needed for the upgrade). Details 
and examples are provided in clause 7.5.5.2.1. 

Software upgrade management server (MS): The site of a PP vendor, or operated on behalf of a PP vendor, where 
information about new software image releases for handsets, and their locations (on the downloading server) can be 
found. 

Software upgrade downloading server (DS): The site of a PP vendor, or operated on behalf of a PP vendor, from 
where the software image releases can be downloaded. 

7.6.2.1.2 SUOTA general description 

The "Software upgrade over the air" feature allows the software (or firmware) upgrade of a New Generation DECT, 
part 4 PP in front of a New Generation DECT, part 4 FP. This software may be made of one or several files sharing the 
same version. The SUOTA feature includes procedures for: 

information exchange in the C-Plane; and 

actual downloading of the software (or firmware) by the PP. For this download, the "Binary content 
download" feature is used (i.e. using an HTTP connection is used between the PP and the FP). Implementation 
of the "Binary content download" feature is therefore a prerequisite for the SUOTA feature. 

As an addition to the "Binary content download" model, the SUOTA feature uses an extra "middle tier" on the FP 
which exchanges software upgrade specific commands with the PP and issues its own requests toward the management 
server. 

The SUOTA feature defines the following two types of SUOTA. Both SUOTA types use a common PP to FP protocol. 

1) Basic SUOTA is described end-to-end from PP to MS and from PP to DS, and uses plain http up to the 
servers. FP to MS protocol is the object of annex B. 

2) Enhanced SUOTA enables the use of a non limited list of optional additional features for the FP to MS 
exchanges (authentication, confidentiality, device identification, etc). 

NOTE 1: Enhanced SUOTA is expected to be used mostly in the case of telecom operator managed devices. 

Only the PP or MS can decide to use enhanced SUOTA; otherwise, basic SUOTA shall be used by the FP. In enhanced 
SUOTA, although the FP to MS protocol is enhanced, URLl received from the PP shall still be used by the FP as an 
entry point to the MS. 

NOTE 2: This means that with enhanced SUOTA, the FP to MS protocol should still be http based. 

NOTE 3: Use of enhanced SUOTA by the PP/MS can only be successful if the FP implements the needed enhanced 

features. 
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Multiple handset systems 

In multiple handset systems, each handset handles SUOTA independently. In case of simultaneous attempts from 
several PPs, the FP could reject all but one attempt from them (using a "Retry later" negative acknowledgement for the 
other, see clause 7.5.5.2.4). 

FP upgrade 

Although the SUOTA feature only deals with the upgrade of PPs, a FP implementing the feature shall be capable of 
firmware upgrade of itself (with a software upgrade method outside the scope of the present document). 

The SUOTA process for a PP shall not be interrupted by the upgrade of the FP. 

Upgrade of the FP shall always guarantee that the FP is still compatible with the implemented features of the present 
document as a result of the upgrade. In particular, this means that PPs shall still be able to use SUOTA. 
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Figure 14: Software upgrade overview 

The SUOTA feature comprises 4 steps summarized in figure 14 above and further detailed in clause 7.6.2.2: 

Steps 1, 3 and 4 are repeated as many times as there are files to be downloaded for a given software upgrade: 
the PP carries out step 1 again after step 4, until URL2 in the response (step 3) is absent. 

Step 2 is the step in which the FP retrieves the next file to be downloaded. First use of step 2 by the FP 
includes a request to MS (FP_URL1), in order to get all file urls needed for the upgrade (FP_URL2n, 
1 < n < Nf). In the next uses of step 2, the FP retrieves the next file url locally. 

NOTE 1: A PP may hold several URLl values. See clause 7.6.2.2.1. 
For the description of the SUOTA feature, the following definitions apply: 
URLl: URLl is defined as a PP -embedded URL entry point to the PP vendor management server. 

NOTE 2: A PP could hold several URLl values. See clause 7.6.2.2.1. 
FP_URL1: request url to the MS, used to retrieve the set of file urls needed for the upgrade. 

NOTE 3: If the FP to MS interface of annex B is used, FP_URL1 is equal to URLl with appended parameters. 
FP_URL2: Url variable representing the current file url to be downloaded, from FP point of view (retrieved in step 2). 
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URL2: Url variable representing the current file url to be downloaded, from PP point of view. URL2 is used by the PP 
in the "Binary content download" feature from PP to FP. URL2 may be equal or not to FP_URL2 depending on the 
used scenario (see clauses 7.6.2.2.3 and 7.6.2.2.3 for details). 



7.6.2.1.4 



SUOTA protocol steps: overview 



The "Software upgrade over the air" protocol comprises the 4 steps defined in the following sub-clauses. These steps 
are used several times. First use of step 2 is remote, subsequent uses of step 2 are local. Figure 15 summarizes the use of 
these steps. 
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Figure 15: Software upgrade overview sequence chart 

NOTE 1 : FP_URL2 1 , FP_URL22, . . . may be forwarded as is to the PP (URL2 = FP_URL2 1 , etc) or a transient 
URL2 value pointing to the FP itself may be used instead. 
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NOTE 2: Retrying software upgrade allows to systematically notify the management server of successful software 
upgrade. In case of so-called "multiple step" software upgrade, the whole process is restarted (in that case, 
the MS sends a new set of URL instead of "no url"). See clause 7.6.2.5. 

NOTE 3: A single PP upgrade may imply the download of several files (cf. the "fileNumber" parameter in the 
handset version indication command of clause 7.5.5.2.1). Hence the optional "multiple file" block for 
downloading files 2 to Nf (Nf > 2). 

7.6.2.2 Basic SUOTA protocol steps 

Use of Basic SUOTA is illustrated in clause B.3. 

7.6.2.2.1 Step 1 -PP sends a "Handset version indication" command to the FP 

In step 1, the PP sends to the FP a "Handset Version indication" command as defined in clause 7.5.5.2.1. This command 
shall be sent: 

• either following an "external triggering event" as defined below. In that case the "fileNumber" parameter of 
this command is set to "1", indicating that the first file for the software upgrade to come (if any) is requested. 
In that case, the <URL to follow> field shall be set to "1". 

• or following step 4 (clause 7.6.2.2.4) in order to loop over the steps to retrieve subsequent files (in case more 
than one file is needed, i.e. in case of multiple file software upgrade). In that case, the <URL to follow> field 
should be set to "0". 

External triggering event. Event triggering the overall software upgrade process. The following external triggering 
events types shall be supported: 

1) "periodic attempt" (coded in the PP for regularly checking availability of a new version); 
EXAMPLE: The PP could for example send a "Handset version indication" command every 5th day. 

2) "successful software upgrade". See clause 7.6.2.6, "Final notification of success and multiple step 
SUOTA" for details. 

The following external triggering event types may be supported: 

3) "push" (if software upgrade is triggered by an MS originating message). See clause 7.5.6 for details. 

4) "user initiated SUOTA". See clause 7.6.2.7, "User initiated SUOTA" for details. 
Command parameters. The "Handset version indication" command includes, among other parameters: 

• The <URL to follow> parameter, indicating presence of URLl in a subsequent "URL indication" command. 
URLl is the entry point to the management server (only present for the first use of step 1). 

• The current "Software version identifier" of the software installed on the PP and to be upgraded. Goal of the 
"Software upgrade over the air" feature is the download of a newer version. In case installation of a new 
version requires uninstallation of the previous version, the previous version identifier shall still be used. 

• The value of a file counter ("fileNumber"), indicating the number of the requested file. To request the first file, 
the fileNumber parameter shall be set to "1". 

NOTE 1: A PP may hold several URLl values, especially to provide for the case the FP would not implement a 
security requirement included in one of them (see clause 7.6.2.4). Additionally, a different URLl value 
could be tried if a "negative acknowledgement" (see clause 7.5.5.2.4) of type "unreachable URLl (server 
error)" is received from the FP in response to a "Handset Version indication" command. 

Between two consecutive uses of the "Handset version indication" command, the "Software version identifier" shall not 
change, unless the new software image has been completely downloaded and installed in between (i.e. all files for the 
new version were received). 

NOTE 2: In contrast to this, the "Handset version available" command sent in step 3 as a response from FP to PP 
should contain the new "Software version identifier". 
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Between two uses of the "Handset version indication" command with the same "Software version identifier", the PP 
shall increment the value of the "fileNumber" parameter by 1, in order to get the next file url in the subsequent "Handset 
version available" command. Incrementation of the parameter shall also be interpreted by the FP as a notification of 
correct download and handling of the previous file by the PP. 

Error handling: The PP shall not use the same "fileNumber" value twice for the same "Software version identifier", 
unless: 

• it has not received the corresponding response; 

• it uses it to notify a failure as specified in clause 7.6.2.6, "Notification of failure", with a non-zero reason field. 
This includes possible requests for a new delay if the PP built-in download window cannot be respected. Use 
of a non-zero value shall imply contacting the MS in step 2. 

7.6.2.2.2 Step 2-FP retrieves url of the next file to be downloaded (FP_URL2) 

In step 2, the FP retrieves the url of the next file to be downloaded (called FP_URL2jj) either locally or remotely from 
the management server. 

The first time step 2 is used (n = 1), the FP shall contact the MS in order to retrieve the set of all FP_URL2 values (if a 
new software version is available). The FP determines the request to be used toward the MS for this purpose (called 
FP_URL1). More specifically: 

• the FP shall construct FP_URL1 using URLl received from the PP as a base URL. 

• FP_URL1 shall be constructed by appending device specific information to URLl, as defined in clause B.l, 
"Basic SUOTA FP to management server interface". 

• the FP shall send an HTTP GET request to FP_URL1 on the MS. 

NOTE: The FP should be prepared to receive an HTTP redirection status code (3xx) as a result of using URLl . 

Based on the received parameters, the MS returns the download information for the next software version, including the 
set of all needed FP_URL2 values (Nf values, with 1 < Nf < 15, or values if no new software version is available). 

The download information is received as text information with "Content-Type" value of "application/xml", as described 
in clause C.2, "Basic SUOTA management server to FP interface". 

In the next uses of step 2 (n > 1), FP_URL2jj is retrieved locally in the FP. 

7.6.2.2.3 Step 3-The PP receives the "Handset version available" command from the FP 

In step 3, the FP sends a "Handset version available" command defined in clause 7.5.5.2.2, to the PP. This command 
shall always be sent upon reception by the FP of a "Handset version indication" command. 

Upon reception of a "Handset version indication" command with a given "Software version identifier", and with a 
"fileNumber" field equal to "n" (i.e. for the "n* use" of step 3), the FP shall follow one of the following options: 

Option 1: If there is no new software image available, the FP shall reply with a "Handset version available" 
command with a <URL to follow> field set to "0" ("No url" response). This should only be used once, when 
n="l". 

This reply shall end the Software upgrade process on PP side (and until a future triggering event occurs). 

Option 2: Or, if a new software image is available, and 1 < n < Nf, the FP shall reply with a "Handset version 
available" command, which: 

shall contain the "Software version identifier" of the new software image (i.e. necessarily different from 
the value sent in the "Handset version indication" command); 

shall contain a <URL to follow> field set to "1" and shall be followed with a "URL indication" command 
containing URL2n, to be used by the PP in step 4 for downloading the n'^ file (see "URL2i, value 
determination" below). 
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Option 3: Or, if a new software image is available, and n > Nf, the FP shall reply with a "Negative 

acknowledgement" command, with reason field "File does not exist". This should never happen and is an error 
case, as the PP having received the needed Nf files should have installed the new software version already. In 

that case the PP shall revert to a stable version if possible. 

Option 4: Or, if the reason field in the "Handset version indication" was non-zero indicating a PP failure and 
implying contacting the MS in step 2, the FP shall answer to the PP according to the provisions of 
clause 7.6.2.6, "Notification of failure". 

"No url" (option 1): Two main situations lead to option 1 above: 

an external event triggered the sending of this command (reboot, periodic attempt, etc), but the PP had an 
up-to-date version installed; 

the PP just completed the installation of a new software version (having received all files pertaining to that 
version) and sends this command in order to allow for a possible multiple-step software upgrade (see step 1, 
clause 7.6.2.2. l)-but there is no additional step foreseen on MS side. This can be considered a subcase of the 
previous situation. 

URL2i, value determination (option 2): In option 2 above, URL2n shall be equal to FP_URL2n. In other words, the 
FP forwards FP_URL2n received from the MS "as is" to the PP. 

NOTE: This is not necessarily the case when Enhanced SUOTA is used, see clause 7.6.2.3.3. 
DelayMinutes value: The provisions of clause 7.5.5.2.2 shall be respected. 

7.6.2.2.4 Step 4-PP and FP gets the current file from the downloading server 

Step 4 is used in the case option 2 is used in step 3. The PP initiates an HTTP connection to URL2n, using the "Binary 
content download" feature. 

The entry point used on the network side by the FP shall always be FP_URL2n = URL2j,. The FP is almost transparent 
and also uses HTTP toward the network. More specifically, the FP: 

may use HTTP GET partial request toward the network (as the PP does toward the FP when using the "Binary 
content download" feature); 

may adjust the "Range" and "Content-Range" headers to its own memory and data rate constraints. 

After downloading the file, the PP shall use the downloaded file as appropriate (e.g. install it, and possibly install the 
whole new software version if this is the last file), and go back to step 1 again (until the process ends in step 3, option 1, 
when the FP sends a "Handset version available" command with no URL2 value) 

Media type: The PP shall use "Accept: application/octet-stream" header in the request. The only media type used by 
the server in the "Content-Type" header shall be "application/octet-stream". 

NOTE: In the context of the HTTP protocol, media types are used in the "Accept" (from client) and "Content- 
Type" (from server) header fields. Media types allow content type negotiation and content type 
notification. 

Error handling: In case of failure of a GET request during the software image download in step 4: 

If an HTTP error is received from the server, the FP shall forward it as is to the PP. 

If the download was interrupted for any reason, the PP may use additional partial GET requests to retrieve the 
whole file (see clause 7.6.1.4, "File downloading resumption" and clause A. 1.7.3). 

If the download cannot occur and be completed immediately after the "DelayMinutes" value timed out, the PP 
shall follow the provisions of clause 7.5.5.2.2 about the "DelayMinutes" parameter. 



£75/ 



67 ETSI TS 102 527-4 V1.1.1 (2009-10) 

7.6.2.3 Enhanced SUOTA protocol steps 

Enhanced SUOTA is introduced in clause 7.6.2.1.2, "SUOTA general description" and defined in the present clause. 
Enhanced SUOTA re-uses 7.6.2.2, "Basic SUOTA protocol steps" as a prerequisite, but allows some variations. 
Although the set of protocol enhancements usable with Enhanced SUOTA is not limited, the principles described in the 
present 7.6.2.3 clause shall be respected. 

In particular, use of Enhanced SUOTA for the PP upgrade shall always be decided by the PP in step 1, or equivalently 
by the MS in step 2, but never by the FP itself (although it may be initiated by the FP in step 1 in some cases, 
see clause 7.6.2.3.1). 

NOTE 1 : Use of enhanced SUOTA by the PP/MS can only be successful if the FP implements the needed enhanced 
features. 

NOTE 2: Use of Enhanced SUOTA is illustrated with 4 examples in annex C. 

7.6.2.3.1 Step 1 - Enhanced SUOTA possible variants 

The provisions of clause 7.6.2.2.1 (Step 1) apply with the following modifications. 

When using Enhanced SUOTA, URLl received from the PP in step 1 shall be used in any case as an entry point to the 
MS in step 2. 

Enhanced SUOTA initiation in step 1. Enhanced SUOTA may be initiated in step 1 using one of the following 
methods: 

Use of an enhanced feature may be initiated by the PP using security requirements for URLl in step 1 
(see clause 7.6.2.4, "PP security requirements in URLl and URL2" and clause C.l for an example). 

Use of an enhanced feature may be initiated by the FP in step 1, using URLl as a known identifier triggering 
the use of some enhanced features (hence Enhanced SUOTA), although URLl as such does not necessarily 
reflect this (i.e. does not contain any security requirement). This method can only be used if the FP knows the 
PP and MS, and therefore knows that the PP and MS require these features to be used. 

NOTE: For instance, the FP could use HTTP POST method to send data to URLl, instead of the HTTP GET 
method, or initiate an HTTPS session to URLl, etc. See clauses C.3 and C.4 for examples. 

7.6.2.3.2 Step 2-Enhanced SUOTA possible variants 

The provisions of clause 7.6.2.2.2 (Step 2) apply with the following modifications. 

Enhanced SUOTA initiation in step 2: Enhanced SUOTA may be initiated in step 2 using the following method: 

Use of an enhanced feature may be initiated by the MS in step 2 upon reception of a request to URLl or to a 
URLl-based request, if this is a dynamically discoverable feature (e.g. RFC 2817 [24] describes a way for a 
server to initiate a TLS session upon receiving a plain HTTP request, see clause C.2). 

As stated above, with Enhanced SUOTA, URLl received from the PP in step 1 shall be used in any case as an entry 
point to the MS by the FP in step 2. However, if Enhanced SUOTA is used, and in contrast to when Basic SUOTA is 
used: 

The protocol used to retrieve the download information need not be HTTP. 

The FP to MS interface need not be the one described in annex B (whereas Basic SUOTA uses annex B). The 
way needed input parameters are provided to the MS is out of scope of the present document. 

The download information could be retrieved by the FP from the MS in one or several steps, whereas Basic 
SUOTA retrieves all information in one step (in the first use of step 2). 

Whether download information is retrieved locally or remotely in the n* use of step 2 is out of scope of the 
present document (whereas the FP using Basic SUOTA retrieves all information remotely in the P*^ use of 
step 2, and locally afterwards). 
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NOTE: In any case, the file url for the n^^ file (FP_URL2jj) should be retrieved by the FP for the rfi^ use of step 2 
at the latest. 

7.6.2.3.3 Step 3-Enhanced SUOTA possible variants 

The provisions of clause 7.6.2.2.3 (Step 3) apply with the following modifications. 

URL2i, value determination (option 2). If Step 3 option 2 is used (see clause 7.6.2.2.3), and in contrast to Basic 
SUOTA, URL2n sent to the FP may be different from FP_ URL2n received from the MS. 

In any case, the FP shall still keep FP_URL2ji and use it in step 4. 

More specifically, URL2n may be chosen by the FP as a transient "self-pointing URL". 

NOTE: A self -pointing URL points to the FP itself (acting as a local server) and uses "localhost" as its host name 
(see clause A. 1.3.1). 

7.6.2.3.4 Step 4-Enhanced SUOTA possible variants 

The provisions of clause 7.6.2.2.4 (Step 4) apply with the following modifications. 

When using Enhanced SUOTA: 

The "Binary content download" feature is still used between the PP and the FP for transferring the next file to 
the PP. The PP initiates an HTTP connection to URL2ji, using the "Binary content download" feature. 

However, URL2n sent by the FP to the PP could point to an entry point located on the FP itself, the FP acting 
as a local server (the FP hides FP_URL2n from the PP). 

The FP still uses FP_URL2ji received from the MS in step 2 to retrieve the file from the DS. 

NOTE 1: FP_URL2j, in scenario 2 when Enhanced SUOTA is used could in fact be any address from any 
protocol-dependent addressing scheme (it could even not be an URL). 

NOTE 2: The PP may be aware of the use of Enhanced SUOTA, if URL2 received from the FP is local. 

Error handling: In case of failure of a GET request during the software image download in step 4, and as an addition 
to the error cases already handled in clause 7.6.2.2.4: 

If an error is received from the server (potentially non-HTTP based), the FP shall use the most appropriate 
HTTP error toward the PP. 

7.6.2.4 PP security requirements in URL1 and URL2 

The present procedure describes an enhancement of clause 7.6.2.2, "SUOTA protocol steps", allowing the PP to require 
security functions to be used by the FP when retrieving software upgrade information, and when actually downloading 
the software image. 

NOTE 1: Step 2 and step 4 of clause 7.6.2.2 already allow the FP to use alternative mechanisms (possibly involving 
security) even if the PP does not require anything. 

NOTE 2: The present procedure is illustrated in clause C.l (Enhanced SUOTA example initiated by the PP). 

A PP or FP implementing the present procedure shall implement at least one of the procedures described in "URI- 
based PP to FP security requirements" of clause 7.6.1.5. Furthermore, the provisions of clause 7.6.1.5 shall also apply to 
URLl sent via the C-plane. 

A PP using the present procedure shall, as an enhancement to step 1 (clause 7.6.2.2.1), add one or more security 
requirement(s) to URLl sent in the "URL indication" commands following the "Handset version indication" command. 

The PP shall check whether the FP supports all of these requirements before using them. If the FP does not implement 
all of the security functions required in a given URLl value, the PP shall not use this value and shall use another URLl 
value it holds. A PP shall always hold at least one URLl value with no attached security requirement. 
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A FP implementing the present procedure shall, when receiving URLl with security requirements, perform the 
following actions if applicable: 

as an enhancement to step 2 (clause 7.6.2.2.2), make use of all of these security functions when collecting 
software upgrade information from the management server. This only applies if the FP does not ignore URLl 
as specified in step 2 (clause 7.6.2.2.2); 

as an enhancement to step 3 (clause 7.6.2.2.3), transmit FP_URL2 = URL2 with included security 
requirements. This only applies if the FP choose scenario 1 (clause 7.6.2.2.4.1). 

NOTE 3: The management server, inferring that the FP implements theses functions may send FP_URL2 with the 
same security functions. 

7.6.2.5 Final notification of success and multiple step SUOTA 

As specified in clause 7.6.2.2.1, "Step 1-PP sends a "Handset version indication command to the FP", a successful 
software upgrade shall be considered as an external event triggering a "SUOTA attempt" on PP side. 

The corresponding "Handset version indication" command shall contain the new "Software version identifier" (of the 
just installed software version), and a "fileNumber" parameter reset to "1". This allows: 

the PP to systematically notify the MS of a successful software upgrade; 

the MS to possibly initiate a new step of a "multiple step" software upgrade. 

NOTE: A multiple step software upgrade could be needed if a direct upgrade to the target software version is not 
possible or has not been tested. 

7.6.2.6 Notification of failure 

In case the PP is unable to download or install file "n", it shall send a "Handset version indication" command for the 
purpose of notifying the failure to the FP and MS. 

The "reason" field of the "Handset version indication" command shall be set to a non-zero value, as specified 
in clause 7.5.5.2.1, "Handset version indication command". 

The "fileNumber" field (= "n") shall be interpreted as the number of the file, for which "download" or 
"application" (i.e. intended use, for example: installation, reading of contained parameters, etc.) failed. 

The "Software version identifier" field shall still refer to the currently installed version of the software, not to 
the version for which a failure occurred (which is not installed). The MS can identify the failing version from 
the download information it sends in response to this value. 

When using Basic SUOTA, the FP shall in turn notify the MS a specified in clause B.l, setting the reason parameter in 
FP_URL1 to the selected non-zero value (default value when absent is "0"). 

When using Enhanced SUOTA, the way the FP notifies the MS, if it does, is out of scope of the present document. 

Whatever kind of SUOTA is used, in response to a failure notification, the MS: 

may re-send download information (with a possibly updated "DelayMinutes" value); 

should re-send download information with updated "DelayMinutes" value if the "reason" field value was 
"Unable to download in time-New DelayMinutes requested"; 

may indicate "No url" (see "No url" (option 1) in clause 7.6.2.2.3, for details), thus taking into account the 
failure. 

In case the MS re-sends download information, the FP shall answer the PP as usual in a "Handset version indication" 
command: 

with the url for the n'^'^ file, where "n" was the "fileNumber" field value in the "Handset version indication" 
command notifying failure; and 

with the new "DelayMinutes" value received from the MS. 
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7.6.2.7 



User initiated SUOTA 



When a real user originates a SUOTA attempt (e.g. triggering SUOTA through a dedicated menu), and only in that case, 
the "Handset version indication" command shall bear the following modification: 

the "User initiated software upgrade" flag of the "Flags" field shall be set to "1". 

NOTE 1 : Access to this service need not be granted to the end user (e.g. could be reserved for the after-sales 
service). 

When using Basic SUOTA, the FP shall in turn notify the MS as specified in clause B.l, setting the "UIS" parameter to 
"1" in FP_URL1 (default value when absent is "0"). 

When using Enhanced SUOTA, the way the FP notifies the MS, if it does, is out of scope of the present document. 

NOTE 2: Notifying the MS enables a better user experience: the MS could in return grant a "0" value for the 
"DelayMinutes" parameter in the "Handset version available" response. 

7.6.3 HTTP-based applications 



7.6.3.1 



HTTP-based applications general requirements 



The "HTTP-based applications" feature allows easy implementation of user interface based applications, thanks to a 
rendering engine located in the PP. The application code and data are remotely hosted, either in the FP, or in an HTTP 
server, or both. 

NOTE 1 : The "HTTP -based applications" feature does not allow local interactions between the application and the 
PP local APIs. 

There are two different XHTML profiles; the Baseline XHMTL profile (see clause 7.6.3.6) and the Simple XHTML 
profile (see clause 7.6.3.5). 

The user interface is XHTML based. DECT handset shall implement the "Simple XHTML profile" of clause 7.6.3.5 and 
may implement the "Baseline XHTML profile" of clause 7.6.3.6. Remote applications designed for use on DECT 
handsets implementing one of these profiles shall be DECT specific and only use the subset of XHTML defined there. 
The Baseline profile is defined for ensuring interoperability but remains optional for the PP. 

Implementation of the "Extended HTTP profile" of clause A.2 (including the "Common HTTP Profile" of clause A.l) is 
a pre-requisite for a PP implementing the "Baseline XHTML profile". 

NOTE 2: A FP may also implement server-side "HTTP -based applications" compliant applications. In that case 
requirements applying to a DECT specific server apply to the FP. 
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Figure 16: Remote application using thie "HTTP-based application" feature 
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NOTE 3: An "HTTP based application" based application remote tier (unlike that of a "Binary content download" 
based application) works on any PP implementing the used XHTML subset (i.e. does not need to be 
hosted by the PP vendor). 

NOTE 4: The remote tier of an "HTTP based application" based application (unlike that of a "Binary content 
download" based application) may be located on the FP. 

7.6.3.2 Support of additional HTTP header fields 

In addition to the uses of HTTP header fields defined in clause A. 1.4, the PP shall support the following header fields, 
or new uses of these fields. 

Table 26: Additional HTTP header fields 



Name 


Direction 


PP 
status 


FP 
Status 


Normative action/comment 


Accept 


PP to FP 


M 


M 


Additional use for describing the type of audio, image files 
supported. See clause 7.6.3.3. 


Accept-charset 


PPtoFP 


M 


M 


To indicate support of UTF-8, iso-8859-1 and possibly 
additional charsets (see note 1) 


User-Agent 


PP to FP 


M 


C3601 


Possible values for version Part4 version 1.1.1: 

- NG-DECT-Part4/1 .1 .1 (A.I ; A.2; NGLDS-A.3) 

- NG-DECT-Part4/1.1.1 (A.I; A.2; NGLDS-A.3; 7.6.3.6) 
See also clause A. 1.4 


C3601 : IF the FP plays the server role THEN M ELSE N/A 



NOTE: HTTP uses the phrase "character set" (abbreviated as "charset"), whereas "character encoding" would be 
more appropriate. 

7.6.3.3 Support of additional media-types 

When the PP requests a media file of a given media type (e.g. "image", "audio", etc) with the GET method, the PP 
should use the "Accept" header in order to indicate to the server its preferred subtype(s) for the given media type. The 
server then indicates the actual subtype used in the "Content-Type" header of the response. 

NOTE 1: In the context of a binary content download (see clause 7.6.1), an image or audio file may be sent with the 
"application/octet-stream" media type. 

NOTE 2: Absence of the "Accept" header means that the PP accepts all media subtypes for the given media 
subtype. 

7.6.3.4 Support of character encodings 

For text based resources that need to be displayed on the screen (text or html file), the media type itself is not enough to 
fully determine the interpretation of the received media. 

The PP shall at least support UTF-8 [i.7] character encoding formats. 

NOTE 1 : Support of UTF-8 only means support of the UTF-8 encoding structure at a minimum. 
For more information see annex E. 

The PP may support ISO/IEC 8859-1 [i.l 1], which is equivalent to support Unicode [i.6] code points from Uh-0000 to 
Uh-OOFF. 

NOTE 2: However, for code points between Uh-0080 and Uh-OOFF, UTF-8 encoding differs from 
ISO/IEC 8859-1 [i.ll] encoding. 

When requesting a text based resource, the PP should notify the server of the accepted character encodings, using the 
"Accept-Charset" header. The PP may support other encoding formats (ISO/IEC 8859-2 [i.l2], 
ISO/IEC 8859-15 [i.l3], UTF-16, etc), that may be easier to use or more concise for some languages. In that case, it 
should also use the "Accept-Charset" header to indicate it. 
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The server should indicate-when sending a document to the PP-the used character encoding, using the "charset" 
parameter of the "Content-Type" header field. The PP shall use this information in order to correctly display the content 
to the user. In case the charset parameter is absent, the PP shall assume that the document is UTF-8 encoded. 

7.6.3.5 Simple XHTML profile 

The PP shall at least support the following XHTMLl.l [27] modules. Text nodes shall use UTF-8 [i.7] encoding. 

NOTE: The "Simple XHTML profile" only requires partial implementation of some modules, as indicated in the 
"Comment" column. 

Table 27: Supported XHTML modules in Simple XHTML profile 



Module 


Element 


Comment 


Structure 


body, head, html, title 


Complete 


Text 


br, p 


Partial 


Hypertext 


a 


Partial (href attribute only) 


Style 


text-align: left/center/right 


Used in <p> 


Presentation 


b 


Partial 



The PP shall understand all listed tags. However, the present document does not enforce the way the information is 
presented to the user. The PP should follow the tag definition whenever possible, and as much as possible, but may use 
alternative ways to render the tag in case of display or other constraints. For example, the PP shall understand (but not 
necessarily follow) the "<b>" tag for bold face presentation: if the PP does not hold the corresponding bold face font, it 
could render it with quotes, or not render it at all. 

7.6.3.6 Baseline XHTML profile 

The PP shall at least support the following XHTMLl.l [27] modules: 

NOTE: The "Baseline XHTML profile" only requires partial implementation of some modules, as indicated in the 
"Comment" column. 



7.6.3.6.1 



Basic elements support 
Table 28: Supported XHTML modules in Baseline XHTML profile 



Module 


Element 


Comment 


Structure 


body, head, html, title 


Complete 


Text 


br, h1,h2, h3, h4, h5, h6, p 


Partial 


Hypertext 


a 


Complete 


List 


ol, ul, li 


Partial. The "value" attribute on "li" 
element restarts numbering 


Presentation 


b, i 


Partial 


Base 


base 


Complete 



7.6.3.6.2 



Image element support 



The "img" tag shall be recognized even if the PP is not able to display images. In that case it may use the "alt" 
(alternate) attribute of this tag in order to display a text replacement for the image. 

Table 29: Supported XHTML modules, image elements 



Module 


Element 


Comment 


Image 


img 


Complete 
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7.6.3.6.3 Tables support 

Table 30: Supported XHTML modules, basic tables 



Module 


Element 


Comment 


Basic Tables 


table, td, tr 


Partial 



7.6.3.6.4 Forms support 

Table 31 : Supported XHTML modules, forms 



Module 


Element 


Comment 


Forms 


form, input, select, option, textarea 


Partial 



Consistently with clause A.2 ("Extended HTTP profile"), a <form> element shall have an enctype field with value 
"multipart/form-data" 



7.7 



Interworking requirements 



NOTE: See also clause 7.6.1.2 on LUlO interworking conventions and HTTP profile. 

7.7.1 IWU-attributes information element 

The procedures as specified in EN 301 649, [15], clauses B.l to B.4 and B.6 shall apply with the following differences: 

• Only Frame relay (FREL) service and Interworking type Generic media encapsulation (clause B.8, [15]) shall 
be used. 

• The coding of the IWU-ATTRIBUTES information element (clause B.2, [15]) shall be as follows: 

Table 32: IWU-ATTRIBUTES information element support status 



Supported parameters | 


Field no. 


Name of fields 


Ref. 


Support 


Values 










Allowed 


Supported 


1 


ID of IWU attributes of 
variable length 




M 


18 




2 


Length of Contents (L) 




M 


to 255 


any 


3 


Coding standard 




M 


1 


1 


3 


Profile 




M 








4 


Negotiation indicator 




M 


0,2,4,6 


0,2 


4 


Profile subtype 


B.2.1 


M 


0to15 


8 


5,5a 


IVIaximum SDL) size 
(PT => FT or both ways) 


B.2.1 


M 


to 16 383 
(equivalent to 
to 131 064 
octets) 


191 to 16 383 
(equivalent to 
1 528 to 131 064 
octets) 


5b, 5c 


Maximum SDL) size 
(FT => PT, optional) 


B.2.1 





Oto 16 383 
(equivalent to 
to 131 064 
octets) 


1 528 to 16 383 
(equivalent to 
12 22410 
131 064 octets) 


6 


Application protocol control 
set 


B.2.1. 1.3 


IVl 


All values for 
Generic 
Encapsulation 
Interworking 


All values for 
Generic 
Encapsulation 
Interworking 


NOTE: See EN 301 649 [15], clauses B.2 and B.8. 
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7.7.2 SDU sizes and setting of SDU boundaries 

The chopping facihty defined in DPRS Generic Encapsulation Interworking (see DPRS [15], clause B.8.2) may be 
optionally implemented to split large application packets into smaller SDUs. This chopping facility, when supported 
shall be announced by means of the IE <SETUP CAPABILITY> (see DPRS [15], clause 12.22), and shall be 
specifically invoked at context creation using the flag described in DPRS [15], clause B. 2. 1.1. 4.1. This facility shall 
only be invoked when supported by both sides. 

When the chopping facility is used, the size of the application packet segments (including the D-GMEP header), shall 
be set as the maximum supported SDU size announced at «IWU ATTR1BUTES», except the last (or the only one) 
segment that may be of smaller size. 

In order to use the chopping facility, the features DPRS-N.33 (Dynamic Parameters Allocation) and DPRS-N.35 
(Service Change) shall be supported. 

Unless the chopping facility is in use, the SDUs shall be equal to an application packet plus the D-GMEP header (see 
DPRS [15], clause B.8.2) 

7.8 Pinysical layer procedures 

No differences/additions - the procedures as specified in EN 301 649 [15], clause 5 shall apply. 
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Annex A (normative): 
HTTP Profiles 

A.1 Common HTTP profile (HTTP limited set nr.2) 

NOTE: The "Common HTTP profile" is the HTTP limited set nr. 2 Hsted in DPRS (EN 301 649 [15], 
clause B.8.3.4). The name "Common HTTP profile" is used locally in the present document. 



A. 1.1 General requirements 



The "Common HTTP profile" defined in clause A. 1 represents the minimum HTTP profile that a New Generation 
DECT, part 4 PPs implementing HTTP based features must implement. This profile is based on HTTP version 1.1 [22]. 

NOTE: The "Common HTTP profile" is a pre-requisite for: 

The "Binary content download" feature (clause 7.6.1). 

The "Software upgrade over the air (SUOTA)" feature (clause 7.6.2). 

The "HTTP-based applications" feature (clause 7.6.3). 

The "Extended HTTP profile" (clause A.2). 

Use of the present annex relies on the interworking conventions defined in EN 301 649 [15] (DPRS), clause B.8.3.1. 

A.I .2 Supported HTTP methods 
A.I. 2.1 GET method 

The PP and FP shall only use HTTP unconditional partial GET requests. 

NOTE: HTTP 1.1 [22] describes conditional and unconditional GET requests. Partial GET requests may be 
conditional or unconditional. 

A GET request in the context of the present "Common HTTP profile", being always "partial", shall systematically 
include a "Range" header field. See clause A. 1.7 for the use of a "Range" header field. 

As requested by version 1.1 of HTTP, such a GET request shall always contain a "Host" header field. 

A. 1.2.2 HEAD method 

The PP and FP should support the HTTP HEAD method, which may be useful for debugging purposes. 

A. 1.2.3 POST method 

When both sides only support the present "Common HTTP profile", the POST method shall not be used by the PP. 

NOTE: DPRS [15], HTTP Hmited set nr. 1 (clause B.8.3.3) and HTTP limited set nr. 3 (clause B.8.3.5) both 
require support of the POST method. This is however not supported within HTTP limited set nr. 2 
(Common HTTP profile) described in clause A. 1 . 

A.I .2.4 Pipelining of requests 

The PP shall not use pipelining of idempotent requests (i.e. GET, HEAD, etc, but not POST) as described in 
HTTP 1.1 [22], section 8.1.2.2. As a result, non transparent FPs need not support the handling of pipelined requests. 
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NOTE: This restriction does not apply to requests from distinct flows or applications, i.e. handled with separate 
contexts as described in DPRS clause B.8 (unless the PP or FP only supports a single context). Such 
flows would use separate TCP connections on the network side anyway. 

A.1 .3 Request URI and Host header field 

Request URI: The request URI is the URI reference included in the request line of an HTTP request. 

NOTE 1: RFC 3986 [23] (section 4.2) defines a URI reference as either a URI or a URI relative reference. This 
RFC obsoletes RFC2396 however referred to by HTTP 1.1. 

A "Common HTTP profile" compliant request URI sent over the DECT air interface shall be either: 

• an absolute path URI relative reference, as in GET /path/file. bin httpI.1. 

• a URI with "http" scheme value, as in the next example: 

EXAMPLE 1 : GET http://suota.example.com/path/file.bin HTTPl.l. 

NOTE 2: An absolute path URI relative reference cannot be empty, and should at least contain the starting slash 
character ("/"). 

A "Common HTTP profile" compliant HTTP request shall contain a "Host" header field, as required by HTTPl.l. 
When an http URI is used as Request URI, the host part of that URI and the "Host" header field value shall be identical. 

Examples of an HTTP Requests (extract): 

EXAMPLE 2: 

GET /path/file. bin HTTPl.l 

Host : content -download. example . com 

EXAMPLE 3: 

GET http://content-download.example.com/path/file.bin HTTPl.l 
Host : content-download . example . com 

NOTE 3: An HTTP request sent to a proxy should contain a full http URI. If the FP is behind a proxy, the FP may 
have to modify the request URI before forwarding the request to the proxy. A full http URI can be 
constructed from an absolute path URI relative reference using the mandatory "Host" header field value. 

A. 1 .3. 1 Use of the 'localhost' Host value 

When the "Host" header field value "localhost" is sent over the DECT air interface, it shall refer to the FP. 
Example of Request URIs targeting the FP: 

GET /FPservicel/conf ig. txt HTTPl.l 
Host: localhost 
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A.1 .4 Supported HTTP header fields 

The following HTTP header fields shall be supported by the FP and/or PP according to the following table. 

Table A.1 : Supported HTTP hearer fields 



Name 


Direction 


PP status 


FP Status 


Normative action/comment 


Host 


PPtoFP 


M 


M 


Presence M in all (partial) GET requests 


Accept 


PP to FP 





CA101 


Absence means support of all media 
subtypes 


Content-Type 


FP to PP 


M 


CA101 




Content-Length 


FP to PP 


M 


CA101 




Location 


FP to PP 


M 


CA101 


See A. 1.6. 


User-Agent 


PP to FP 


M 


CA101 


This header shall include the following 

substring: 

"NG-DECT-Part-4/<part 4 version> 

(comment)" 

The comment shall include a semi-colon 

separated list of optional clauses or features 

that are implemented. 


Byte-range operations related headers (see also clause A.1 .7) 


Range 


PP to FP 


M 


CA101 


Presence M in all (partial) GET requests 


Content-Range 


PP to FP 


M 


CA101 


Presence M in successful GET responses 
(206 Partial Content) 


CA101: IF the FP plays the server role (see clause A.1. 3.1) THEN M ELSE N/A. 



The PP shall ignore a header that it does not understand. It shall not reject the response as a result. 

NOTE: Clause 7.6.3.2 defines an amended value for PPs implementing the "HTTP -based applications" feature. 

EXAMPLE: Examples of product token and related comment: a PP implementing New Generation DECT, 
part 4 version 1.1.1 must include one of the following strings in the User- Agent header: 

- NG-DECT-Part4/l.l.l (A.1) 

- NG-DECT-Part4/1 . 1 . 1 (A. 1 ; A.2) 

- NG-DECT-Part4/l.l.l (A.1; A.2; NGLDS-A.3) 

- NG-DECT-Part4/l.l.l (A.1; A.2; NGLDS-A.3; 7.6.3.6). 



A. 1.5 Supported media types 



At least media type = "application/octet-stream" shall be supported (i.e. requested/accepted) as content type by both PP 
and FP. 

NOTE: In the context of the HTTP protocol, media types are used in the "Accept" (from client) and "Content- 
Type" (from server) header fields. Media types allow content type negotiation and content type 
notification. 

A.1 .6 Redirections of GET (or HEAD) requests 

In the context of clause A. 1, a redirection received from the server in an HTTP response indicates that the client must 
issue a new HTTP request in order to get the requested resource. A redirection is characterized by an HTTP status code 
of the 3xx class in the HTTP response. The url for the new request is indicated in the "Location" header of the response. 

NOTE 1 : In general, the exact behaviour of the PP upon redirection depends on the status code received. See 
HTTP 1.1 [22], section 10.3 for details. 

NOTE 2: Redirections of POST requests are possible. However, clause A.1 restricts itself to GET (and HEAD) 
requests. Redirections of GET (or HEAD) requests may be handled by the PP without user interaction. 

NOTE 3: For the redirections of POST requests, see clause A.2. 



£75/ 



78 



ETSI TS 102 527-4 V1.1.1 (2009-10) 



The PP shall be able to handle redirections of GET requests with the following status codes: 

301, "Moved Permanently". If subsequent requests to the same initial url are planned, the PP may use the 
redirection target url ("Location" header value) instead of the initial url. 

302, "Found". If subsequent requests to the same initial url are planned, the PP shall however still use the 
initial url (e.g. for the case the redirection target would change in between). 

307, "Temporary Redirect". In the context of a GET (or HEAD) request, the PP behaviour shall be identical as 
when 302 is used. 

NOTE 4: The behaviour of the PP upon 301, 302, or 307 redirections is similar, except in case subsequent requests 
to the same initial url are planned. 

The PP shall therefore also support the "Location" header of the corresponding HTTP response. 

NOTE 5: For the redirections of POST requests, the PP should also be able to handle the 303 status code. 



IWFPP 



GET /file. bin HTTP/1.1 



IWFFP 



GET /file. bin HTTP/1.1 



Server 



Accept: application/octet-stream 
Range: bytes=0- 199999 
Host: dect.example.com 

HTTPl.l 3 07 Temporary Redirect 



Accept: application/octet-stream 
Range: bytes=0- 199999 
Host: dect.example.com 

HTTPl.l 307 Temporary Redirect 



Location: http://suota.example.com/file.bin 



GET /file. bin HTTP/1.1 



Location: http://suota.example.com/file.bin 



GET /file. bin HTTP/1.1 



Accept: application/octet-stream 
Range: bytes=0- 199999 
Host: suota.example.com 



Accept: application/octet-stream 
Range: bytes=0- 199999 
Host: suota.example.com 



Figure A.1 : Example of redirection handled by the PP 

NOTE 6: A redirection in general may also change the name of the file to be retrieved. This is however not 
recommended for the "Binary Content download" feature (file oriented feature). 

The FP shall not handle redirections on behalf of the PP. 

A.1 .7 Byte-range operations 

Resource: A file available over the Internet at a location specified by a URI. 

Byte-range: A connex subset (interval) of the requested resource considered as a series of bytes. More specifically, a 
byte range is defined as a sub-interval of [0, (L-1)], where "L" is the total length of the resource. 

HTTPl.l byte -range mechanism shall be used systematically by the PP in order to: 

limit the number of bytes received as a response to a single HTTP request; 

resume the downloading of a resource following a broken connection. 

As a restriction to HTTPl.l a PP shall only request a single range of bytes in any byte range request. 

NOTE: For low-memory FPs, the HTTP server hosting DECT specific content to be downloaded should also 
implement range requests. 

The PP and the FP shall implement the following subset of HTTP 1 . 1 byte range operations. 
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A.1 .7.1 Byte-range operations related responses 

206 Partial Content: (RFC 2616 [22], section 10.2.7). This is the response for a successful byte range request (instead 
of "200 OK"). 

NOTE 1: A response with status code 206 should not include a Content-Range header with "*" as the response 

range specifier, as in: Content -Range : byte */200000. 

416 Requested Range Not Satisfiable: (RFC 2616 [22], section 10.4.17). This is to be used when none of the 
requested ranges has a non-empty intersection with the targeted resource. 

NOTE 2: A 416 response should include a Content-Range header one of the following forms: 
Content -Range : byte */L, where L is the total length of the resource. 
Content -Range : byte */*, if the length of the resource is unknown. 

A.1 .7.2 Byte-range operations related header fields 

HTTPl.l defines the following range request related headers. 

Range (from PP to FP): This is the header used by a PP to make a byte-range request. As a restriction to HTTPl . 1 
"Range" header format, the PP shall always request a single range at most. 

NOTE 1 : The use of this header by the FP to retrieve resources from the network is out of the scope of the present 
specification and is not affected by this restriction. The FP should also use this mechanism toward the 
network in order to cope with its own limited byte rate or memory resources. 

Content-Range (from FP to PP): This header shall be used by the FP to specify the actual range of bytes sent as a 
response to a byte-range request. 

NOTE 2: The actual content range may be smaller than the requested one. 

NOTE 3: HTTP 1.1 requires that a Content-Length header be also sent along with the Content- Range header 
(redundant information). 

Accept-Ranges (from FP to PP): If present from FP to PP, this header shall always have the value "bytes" (default 
value), indicating to the PP that range requests are accepted. It shall never have the value "none". 

NOTE 4: For low-memory FPs, the HTTP server hosting DECT specific content to be downloaded should 

implement range requests for all available resources and never use the "Accept-Range: none" value . 

If-Range: Not supported. 

A.1 .7.3 Byte range operation use cases 

This clause describes the HTTP message flows for various use cases. 

NOTE: For the sake of simplicity: 

DECT messages are left out. Each following "GET" message can be part of the same or of a newly 
established DECT connection. 

FP to servers exchanges conform to the scenario described in clause B.3 (almost transparent FP). 

A.1 .7.3.1 Use case 1 : standard downloading with default application packet size of 
1 2 kbytes 

In the following use case, an image file of 120 kbytes is downloaded using ten HTTP GET commands with HTTP 
packet size set at the default value of 12 kbytes by means of the RANGE parameter. 
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Table A.2: Use case 1 sizes 



Size of file to be downloaded 


120 000 bytes 


Maximum HTTP packet size over air i/f 


12 000 bytes 


Maximum HTTP packet size over network i/f 


12 000 bytes 



IWFPP 



IWFFP 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-11999 



HTTPl.l 2 06 Partial Content 



Content - Range : by t es= -11999/120000 

Content -Length: 12 000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host : suota . example . com 

Accept: application/octet-stream 

Range: bytes=12000-23999 



HTTPl.l 206 Partial Content 



CO 



Content - Range : by t es = 12000-23999/120000 

Content -Length: 12000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=108000-119999 



HTTPl.l 206 Partial Content 



Server 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-11999 

HTTPl.l 2 06 Partial Content 



Content -Range : bytes=0 - 11999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=12000-23999 

HTTPl.l 206 Partial Content 



Content -Range : bytes = 12 000-23999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



K3 



^ GET /image. img HTTPl.l 



Content -Range: bytes=108000-119999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



a 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=108000-119999 

HTTPl.l 206 Partial Content 



Content - Range : by t es = 108000-119999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



Figure A.2: Use case 1 : standard downloading with default application packet size of 12 kbytes 

A.1 .7.3.2 Use case 2: standard downloading with application packet size of 48 kbytes 

In the next use case, both peers have announced the support of a maximum application packet size of 48 kbytes (or 
possibly larger) in the «SETUP CAPABILITY» IE, by means of DPRS-N.33 "Dynamic parameters allocation". 

The same image file of 120 kbytes is downloaded using three HTTP GET requests with a range width of 48 kbytes. 

Table A.3: Use case 2 sizes 



Size of file to be downloaded 


120 000 bytes 


Maximum HTTP packet size over air i/f 


48 000 bytes 


Maximum HTTP packet size over network i/f 


48 000 bytes 
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IWFPP 



IWFFP 



Server 



Dynamic Parameters Allocation (either at ACCESS RIGHTS or at LOCATE REQUEST) with maximum 
application packet size (FT=>PT) of 48 kbytes or larger announced in «SETUP CAPABILITY» 



Call Setup 



I 



I 



Service Change (IWU-Attributes change to change maximum SDU size): max SDU size (FT=>PT) set 

at 48 kbytes in «IWU-ATTRIBUTES» 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-47999 



HTTPl.l 2 06 Partial Content 



Content -Range: bytes=0 -47999/12 0000 

Content -Length: 48000 

Content-Type : application/octet-stream 

GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=48000-95999 



HTTPl.l 206 Partial Content 



Content - Range : by t es =4 8000-95999/120000 

Content -Length: 48000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=96000-119999 



HTTPl.l 206 Partial Content 



Content -Range: bytes=96000-119999/120000 

Content-Length: 24000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-47999 

HTTPl.l 2 06 Partial Content 



Content -Range: bytes=0-47999/120000 

Content -Length: 48000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=48000-95999 

HTTPl.l 206 Partial Content 



Content -Range: bytes=48000-95999/120000 

Content-Length: 48000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=96000-119999 

HTTPl.l 206 Partial Content 



Content - Range : bytes= 9 6000-119999/120000 

Content -Length: 24000 

Content-Type : application/octet-stream 



Figure A.3: Use case 2: standard downloading with application packet size of 48 kbytes 

A.1 .7.3.3 Use case 3: Download with interruption in-between 

In this use case, a connection break down makes it necessary for the PP to issue the interrupted GET request again (see 
also "file downloading resumption" in clause 7.6.1.4). 

Table A.4: Use case 3 sizes 



Size of file to be downloaded 


120 000 bytes 


Maximum HTTP packet size air i/f 


12 000 bytes 


IVIaximum HTTP packet size over network i/f 


1 2 000 bytes 
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IWFPP 



IWFFP 



GET / image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-11999 



HTTPl.l 2 06 Partial Content 



Content - Range : by tes= -11999/120000 

Content -Length: 12 000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=12000-23999 



HTTPl.l 206 Partial Content 



Content - Range : by tes= 1 2000-23999/120000 

Content -Length: 12 000 

Content-Type : application/octet-stream 



Server 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=0-11999 

HTTPl.l 2 06 Partial Content 



Content -Range: bytes=0- 11999/12 0000 

Content -Length: 12000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=12000-23999 

HTTPl.l 206 Partial Content 



Content -Range: bytes=12000-23999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



DECT connection interrupts after having received 15430 bytes. 
Second request above is issued again 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=12000-23999 



HTTPl.l 206 Partial Content 



Content - Range : by t es= 1 2000-23999/120000 

Content -Length: 12 000 

Content-Type : application/octet-stream 



GET /image. img HTTPl.l 



Host: suota.example.com 

Accept: application/octet-stream 

Range: bytes=12000-23999 

HTTPl.l 206 Partial Content 



Content -Range: bytes=12000-23999/120000 

Content-Length: 12000 

Content-Type : application/octet-stream 



Figure A.4: Use case 3: Download with interruption in-between 



A.1 .8 Supported HTTP errors 



The PP shall be prepared to receive HTTP status codes related to client errors (of the form 4XX) or server errors (of the 
form 5XX) and shall not crash as a result. 

NOTE 1 : Both client or server error codes are originating from the server as a response to a request. The server is 
supposed to know which side the error comes from. 

NOTE 2: Redirection (3XX) status codes to be supported are documented in clauses A. 1 .6 and A.2.2.2 (for PPs 
implementing clause A. 2). 

NOTE 3: See RFC 2616 [22], section 10, "Status Code Definitions" for a list of status codes. Note however that this 
RFC does not list all existing codes. See for example RFC 2817 [24], section 7.1. 
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A.2 Extended HTTP profile (HTTP limited set nr.3) 

NOTE 1: The "Extended HTTP profile" is the HTTP limited set nr. 3 Hsted in DPRS (EN 301 649 [15], 
clause B.8.3.5). The name "Common HTTP profile" is used locally in the present document. 

The "Extended HTTP profile" defined in the present annex defines a strict superset of the "Common HTTP profile" 
defined in clause A.l and is designed for applications requiring higher interactivity between the user and the 
application. 

NOTE 2: The "Common HTTP profile" limits user inputs to the server to URLs values. The "Extended HTTP 
profile" allows to send parameters or other data to the server. 

NOTE 3: The "Extended HTTP profile" is referenced in: 

The "Binary content download" feature (see clause 7.6.1.6). 

The "HTTP-based applications" feature (7.6.3). 



A.2.1 General requirements 



A PP and FP implementing the "Extended HTTP profile" shall implement the "Common HTTP profile" as a 
pre-requisite. 

The "Extended HTTP profile" implies implementation of the POST method with the "Post Redirect Get" pattern" 

(clause A.2. 2. 2.2). 

A FP implementing the "Extended profile" shall be able: 

• to support the reception of a POST request of at least 1 500 bytes from the PP. 

• to forward such a POST request (received from the PP) to the server. 

• to forward the server response to the PP. 

A PP or FP implementing the "Extended HTTP profile" shall be able to support a POST response of at least 1 024 
bytes. 

NOTE: The server should either respect this limit for the response, or redirect the POST request as defined in 

clause A.2. 2. 2. 2. 

A.2.2 POST method 

This clause describes the use of HTTP 1.1 POST method within the "Extended HTTP profile". This method is provided 
in addition to the partial GET method (see clause A.l) for allowing PP to FP sending of data (i.e. not limited to the 
sending GET requests). 

A PP implementing the POST method feature shall support the POST method with media type "multipart/form-data". 

NOTE 1: The POST method is most notably useful for sending HTML completed forms (see also clause 7.6.3.6.3) 
to the server. However, the user interface for sending user entered data may be any type of user interface 
and need not be HTML forms. 

NOTE 2: The "multipart/form-data" format is known to properly handle character encodings, contrary to GET 
"query string" method(s) or related "x-www-form-urlencoded" POST method, for sending completed 
form data. 
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A.2.2.1 Example of POST method 



Example of form sending 




Comments 


POST /dect/servicel HTTP/1 . 1 ' OdOa' H 


"OdOa'H = carriage return + line feed 


Accept: text/html 'OdOa'H 




(always) 


Content-Type : multipart/form-data 


; boundary= 




7d81'0d0a'H 




The used boundary between form entries 


Host: example . dect . com" OdOa' H 




is defined here 


Content-Length: xxx'OdOa'H 






>OdOa'H 




A "blank line' must be present here 


7d81>0d0a'H 






Content-Disposition: form-data; 






name="Firstname" "OdOa'H 






Content-Type : text/plain; charset= 


UTF-8>0d0a'H 




'OdOa'H 




A "blank line' must be present here 


'c389'Hric'0d0a'H 




'Eric' was entered on a UTF-8 


7d81'0d0a'H 




compliant device 


Content-Disposition: form-data; 






name="Lastname" ' OdOa' H 






Content-Type : text/plain; charset= 


UTF-8'OdOa'H 




'OdOa'H 




A "blank line' must be present here 


Leb>c593'Huf' OdOa'H 




"Lebffiuf was entered on a UTF-8 


7d81-- 'OdOa'H 




compliant device 

The last boundary line must end with 

two hyphens ( " - - ' ) 



Figure A.5: Example of POST method 

NOTE 1 : Considering the POST request as a series of bytes, the following notation has been used in the above 
example: 

bytes corresponding to printable US-ASCII characters are represented by the corresponding 
character. 

hexadecimal notation has been used for non- ASCII characters, and for ASCII but non-printable 
characters (i.e. carriage return character 'OD'H and line feed character 'OA'H). 

white spaces within request and header lines always stand for the single byte '20'H (no other 
encoding should be used for white spaces at these places). 

NOTE 2: A POST request can also send binary data-or data considered as binary data-to the server (e.g. a file), 
although this is not shown in the above example. 

A.2.2.2 Redirection of POST requests 
A.2. 2.2.1 General requirements 

As an addition to clause A. 1 .6, the present clause handles the redirection of POST methods. 
The PP shall be able to handle redirections of POST requests with the following status codes: 

302, "Found". In the context of a POST request, the PP behaviour shall be identical to as when 303 is used. 

303, "See Other". The redirection target url ("Location" header value) shall be requested with a GET request 
(and not POST). If subsequent requests to the same initial url are planned, the PP shall however still use the 
initial url. 

307, "Temporary Redirect". If subsequent requests to the same initial url are planned, the PP shall however 
still use the initial url (e.g. for the case the redirection target would change in between). 
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A.2.2.2.2 Post-Redirect-Get pattern 

The Post-Redirect-Get pattern is known to allow adequate user experience when sending form data to a server. 

In the case of a DECT PP, it also allows the use of a partial GET request by the PP (as described in clause A. 1.7) to 
retrieve the POST response. 

Use of this pattern is initiated by the server which redirects the client instead of sending the POST response directly. 
The client retrieves the response by issuing a subsequent GET (partial) request as the result of the redirection. 

The server should either use this pattern to handle POST requests, or respect the limit defined in clause A.2.1 for the 
size of the response. 

NOTE: The most adequate http redirection code to be used in this case is "303 See Other". 



















IWh rr 


IWh rr 




Server 
















POST /dect/servicel HTTP/1.1 


POST /dect/servicel HTTP/1.1 








Accept: text/html 

Content-Type : multipart/form-data; 

boundary= 7d81 

Host: dect.example.com 
Content -Length: xxx 

7d81 

Content-Disposition: form-data; 

name="Name" 

Content-Type : text /plain, •charset=UTF- 

8 

HTTPl.l 303 See Other 


Accept: text/html 

Content-Type : multipart/form-data; 

boundary= 7d8 1 

Host: dect.example.com 
Content -Length: xxx 

7d81 

Content-Disposition: form-data; 

name = "Name" 

Content-Type : text/plain; charset=UTF- 

8 

HTTPl.l 303 See Other 






Location: 

http : //example . suota . com/response . txt 

GET /response . txt HTTPl.l 


Location: 

http : //example . suota . com/response . txt 

GET /response. txt HTTPl.l 






Accept: application/octet-stream 
Range: bytes=0-199999 
Host: dect.example.com 

HTTPl.l 206 partial content 


Accept: application/octet-stream 
Range: bytes=0-199999 
Host: dect.example.com 

HTTPl.l 206 partial content 






'" Content -Range : bytes = 0- 
119999/120000 
Content -Length: 12 0000 
Content-Type: application/octet- 
stream 

• • • 




'" Content- Range : bytes = 0- 

119999/120000 

Content-Length: 120000 

Content-Type: application/octet 

stream 

• • • 


- 





Figure A.6: Post-Redirect-Get pattern 

A.2.3 Supported HTTP header fields 

Table A.5: Supported HTTP hearer fields 



Name 


Direction 


PP Status 


FP Status 


Normative action/comment 


User-Agent 


PT to FT 


M 


CA201 


The value for version Part4 version 1.1.1 
Shall be: NG-DECT-Part4/1 .1 .1 (A.I ; A.2) 
See also clause A. 1.4 


CA201 : IF the FT plays the server role THEN M ELSE N/A. 
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Annex B (normative): 
Basic SUOTA 



Clauses B.l and B.2 describe the Basic SUOTA interface to the MS, used by the FP. This interface shall be 
implemented by the FP and must be implemented by NG-DECT Part4 compliant management servers. 

NOTE 1: Basic SUOTA is defined end-to-end up to the MS and DS. This allows to handle (at least) the SUOTA 

"pure" cross-vendor case, involving a PP and FP from different vendors, and for which the PP is unknown 
to the FP. 

NOTE 2: The use of this interface is described in clause 7.6.2.2.2, "Step 2- FP retrieves downloading information 
from management server". 

NOTE 3: This interface could also be used for software/firmware upgrade of the FP itself. 

Clause B.3 describes a software upgrade example using Basic SUOTA. 

NOTE 4: Although annex B is normative, clause B.3 only describes an example implementation and is therefore 
informative. 



B.1 Basic SUOTA FP to management server interface 

The purpose of the "Basic SUOTA FP to management server interface" described in the present clause is to allow the 
FP to request the files urls needed for a given software upgrade (see step 2, clause 7.6.2.2.2). 

FP_URL1. Name of the FP request to the management server. For the "Basic SUOTA FP to management server 
interface", this request takes the form of a URL with parameters in the "query string". 

The FP requests all needed file urls at once (i.e. in a single FP_URL1 request). File urls are supposed to be delivered by 
the management server in the order they are needed by the PP for the actual software upgrade, from 1 to Nf. 

B.1.1 FP request (FP_URL1) construction 

In order to construct FP_URL1, the FP shall append the following strings to URLl: 

<linking character>: "?" or "&" or nothing; more specifically, a question mark ("?") shall be used if the base 
url does not contain this character; otherwise, an ampersand "&" shall be used if "?" is not the terminating 
character of the base url; otherwise, the linking character shall be absent. 

"EMC="<coded Equipment Manufacturer's Code value, 4 hexadecimal characters (see note 1)>. 

"&SWVid="<coded Software Version id value, less than 40 hexadecimal characters (see note 1) >. 

"&HWVid="<coded Hardware Version id value, less than 40 hexadecimal characters (see note 1) >. 

NOTE: These values are copied from the "Handset version indication" command received from the PP and coded 
as printable hexadecimal strings. Leading zeros are optional. 

In order to construct FP_URL1, the FP may in addition append the following strings to URLl, and shall do it if it is not 
using the default value for the corresponding parameters: 

"&reason="<reason value from "Handset version indication", 1 hexadecimal character, default value '0'H>. 

"&UIS="<User initiated SUOTA value = bit 5 of octet 8a in "Handset version indication", default value '0'B>. 
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If the reason field is not zero (and therefore necessarily present in FP_URL1), the FP shall in addition add the following 
string to URL 1: 

"&fileNumber="<fileNumber field value from "Handset version indication", 1 hexadecimal character>. 

EXAMPLE: if URL1= "http://suota.example.com/info", FP_URL1 computed as above could be: 

"http://suota.example.com/info?EMC=01ab&SWVid=4649524d574152452d312e322e30&HWVid=322e32, 
in order to ask for download information concerning the version next to "FIRMWARE-L2.0", and provided 
that the <EMC> and <HW Version identifier> values received in the "Handset version indication" command 
were respectively 'Olab'H, '322E32'H. 

"http://suota.example.com/info?EMC=01ab&SWVid=4649524d574152452d312e322e30&HWVid=322e32 
&reason=2&fileNumber=2, to report a failure when applying file number 2 under the same conditions. 

B.1.2 Private parameters 

FP_URL1 may include one or more private parameter(s), if the following conditions are met: 

the FP including these parameters know the MS and knows the MS requires or accepts these parameters; 
each parameter name is different from all of the parameters defined in clause B. L L 
NOTE: For example, an MS specific PP and/or FP device id may be inserted for device management purposes. 

B.2 Basic SUOTA management server to FP interface 

A management server complying with the SUOTA DECT specific interface shall answer the FP request with a 
"application/xml" value for the Content-Type header. 



<?xinl version="l. 0" encoding="utf -8"?> 

<SUOTA> 

<!-- total size in bytes of all files (present or absent in the list below) 
<SoftwareTotalSize>2 0192 7</SoftwareTotalSize> 

<!-- software version id of the file set (printable hexadecimal coded) --> 
<Sof twareVersionId>312e3131</Sof twareVersionId> 

<!-- yes or no; if yes, download should only start upon user authorisation 
<UserInteraction>no</UserInteraction> 

<!-- Delay suggestion (in min) before download should start 

between and 65535 minutes --> 
<DelayMinutes>3 0</DelayMinutes> 

<!-- list of all files needed for the upgrade 

between 1 and 15 files, in the order needed for the upgrade --> 
<FileList> 

<File>http : //suota . example . com/path/ to/ file/fi lei .bin</File> 
<File>http : //suota . example . com/path/to/f ile/f ilel .md5sum</File> 
<File>http : //suota . example . com/path/to/f ile/f ile2 .bin</File> 
<File>http : //suota . example . com/path/to/f ile/f ile2 .md5sum</File> 
</FileList> 
</SUOTA> 



Figure B.1 : Example of management server returned information following a FP request 
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The document element shall be named "SUOTA" and shall contain the following sub-elements: 

• SoftwareTotalSize: total size of the new software (added sizes of all files, present or not in the file list); 
decimal coded. In case there is no new software available, the SoftwareTotalSize parameter shall be "0". 

• SoftwareVersionId: software version identifier of the new software; As the present document makes no 
provision as to the format of the "Software Version id" parameter, it shall be hexadecimal coded. 

• User Inter action: parameter indicating that the user authorization should be received before the download 
starts (value: "yes" or "no", without the quotes). 

• DelayMinutes: (in minutes, from to 65 535). This value is to be used for the first file of the list (As the PP 
downloads files sequentially, the next files will have most of the time a DelayMinutes parameter of "0". See 
clause 7.5.5.2.2). 

• FileList: List of file urls, each of which being included in a sub "File" element. 

In case there is no new software available, the <FileList> element shall still be present, and shall be 
empty. 

File urls shall be listed in the order they are needed by the PP for the actual software upgrade. In case 
several orders are acceptable for the PP, the MS shall nevertheless always use the same order. 

The MS shall respect the order of the elements specified above, and shall not add extra information, such as attributes or 
elements not specified above. 

The FP shall respect the order of the urls in the list, i.e. shall send them in "Handset Version available" commands in the 
same order. 



B.3 Basic SUOTA possible implementation (example) 

Clause B.3 details a possible implementation of Basic SUOTA as described in clause 7.6.2.2. 

Thanks to the information received from the PP in the "Handset version indication" and "URL indication" commands 
(especially URLl): 

The FP creates FP_URL1, by appending PP specific parameters (received in "Handset version indication") to 
URLl (received in "URL indication"). See clause B.l. 

The FP contacts the PP-vendor management server (pp-ms) on behalf of the PP and retrieves the software 
upgrade information there, in the format described in clause B.2. 

The FP forwards to the PP the retrieved FP_URL2 unchanged (FP_URL2 = URL2) in the "Handset version 
available" command. In this example, only one file is needed for the upgrade. 

The PP establishes a "Binary content download" connection with the FP and sends HTTP partial GET requests to the 
FP: 

The FP forwards almost transparently the PP partial GET requests to the DS. 

For a given partial GET request from the PP, the FP may retrieve a smaller or larger range of the target 
resource than requested by the PT, thus adjusting it to its own memory or rate constraints. 
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PP 



FACILITY 



FP 



« IWU-to-IWU handset version indication, URL to follow=1 
FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 

URL content part = URL1 = http : //pp-ms . example . com/info » 



FACILITY 



« IWU-to-IWU liandset version available, software version, 
delay suggestion, URL to follow=1 » 



FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 

URL content part = URL2 = http://pp-ds.example.com/img.bin 



Use of Binary Content Download (7.6.1) for actual software image download 



Downloading 
server 
(pp-ds) 



IVIanagement 

server 

(pp-ms) 



[ 

HTTPS -I- FP authentication 

HTTP GET to FP_URL1 = 

http://pp-ms.example.com/info? 

EMC=01 ab&SWVid=4649524d5741 5 

2452d31 2e322e30&HWVid=322E32 



200 OK 



includes FP_URL2 = 

http : //pp-ds . example . com/img . bin 



FP replaces 
real fp-ds uri 
with self- 
pointing 
(temporary) uri 



Data channel establishment, see clause 7.6.1 .4 



HTTP first partial GET to URL2 = http://pp-ds.example.com/img.bin 
GET /img.bin HTTPl.l 



Host: pp-ds . example . com 

Accept: application/octet-stream 

Range: bytes=0-99999 



HTTPl.l 206 Partial Content 



Partial image file 



HTTP second partial GET to URL2 = http://pp-ds.example.com/img.bin 



GET /img.bin HTTPl.l 



Host: pp-ds . example . com 

Accept: application/octet-stream 

Range: bytes=100000-120000 



HTTPl.l 206 Partial Content 



Partial image file 



GET' request forwarded 
to the network 



H 

'Range' value 
possibly adapted 
(increased or 
decreased) 



->! 



GET' request forwarded 
as above (if needed) 



See note 



Data channel release, see clause 7.6.1.4 



Retry handset version indication', etc... as described in clause 7.6.3.2 



NOTE: For a given partial GET request from the PP, the FP may retrieve a smaller or larger range of the target 
resource than requested by the PT, thus adjusting it to its own memory capacity. In some cases this 
second retrieval step towards the network may therefore not be necessary. 

Figure B.2: Example of Basic SUOTA possible implementation 



£75/ 



90 ETSI TS 102 527-4 V1.1.1 (2009-10) 



Annex C (informative): 
Enhanced SUOTA 



This annexes illustrates 4 possible uses of Enhanced SUOTA, in clauses C.l, C.2, C.3, and C.4. 

C.1 Enhanced SUOTA example-use of 

Basic/Digest authentication and HTTPS 
from FP to IVIS, initiated by the PR 

Clause C.l illustrates one Enhanced SUOTA (clause 7.6.2.3) use case: the use of two enhanced features (https + basic 
or digest http-based authentication from FP to MS) requested by the PP using security requirements as described in 
clause 7.6.3.4, "PP security requirements in URLl and URL2". 

In this example, use of security features from FP to MS implies the use of the same security features for the download 
of the file itself from the DS (i.e. within use of the "Binary content download" feature). This is because the 
MS- inferring from step 2 that the FP is capable of using security features-answers with FP_URL2 also including the 
same kind of security requirements. 

More specifically, exchanges between the FP and the MS, and between the FP and the DS are protected in the following 
way: 

• Confidentiality is ensured through TLS/SSL encryption between the FP and the server: 

For software upgrade information, encryption is requested by the PP by using an https request. HTTPS 
itself is however only used between the FP and the management server. 

For software image downloading, encryption is requested by the MS by including an https url in the 
software upgrade information. HTTPS itself is again only used between the FP and the management 
server. 

NOTE: Encryption only relies on the server encryption private and public keys, and corresponding certificate (the 
FP does not need to own any encryption key). The FP should implement a TLS/SSL stack and 
embed/trust the public key of the server certificate authority, or of one of its ancestors. 

• PP authentication is ensured through HTTP basic or digest authentication, operated by the FP on behalf of 
the PP. 

The PP should entrust the FP with its own authentication password, and therefore should trust the FP. 
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PP 



FACILITY 



FP 



« IWU-to-IWU handset version indication, URL to follow=1 
FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 
URL content part = 

URL1 = https : //pp_id:pp_password@pp-ms . example . com/info » 



FACILITY 



« IWU-to-IWU liandset version available, software version, 
delay suggestion, URL to follow=1 » 



FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 

URL content part = URL2 = https://pp-ds.example.com/img.bin 



Use of Binary Content Download (7.6.1) for actual software image download 



Downloading 
server 
(pp-ds) 



IVIanagement 

server 

(pp-ms) 



[ 

Enciphered and authenticated 

HTTPGETtoFP_URL1 = 

https://pp-ms.example.com/info? 

EMC=01 ab&SWVid=4649524d5741 5 

2452d31 2e322e30&HWVid=322E32 



200 OK 



includes FP_URL2 = 

https : //pp-ds . example . com/img . bin 



Data channel establishment, see clause 7.6.1 .4 



Pseudo HTTPS authenticated partial GET to URL2' = 

https : //pp_id:pp_password@pp-ds . example . com/img. bin 

GET https : //pp_id:pp_password®pp-ds . example . com/img. bin HTTPl.l 



Host: pp-ds . example . com 

Accept: application/octet-stream 

Range: bytes=0-99999 



HTTPl.l 206 Partial Content 



Partial image file 



Pseudo HTTPS authenticated partial GET to URL2' = 

https : //pp_id:pp_password@pp-ds . example . com/img. bin 

GET https : //pp_id:pp_password®pp-ds . example . com/img. bin HTTPl.l 
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Figure C.I : Example of Enhanced SUOTA-use of Basic/Digest authentication and 
HTTPS from FP to MS, initiated by the PP 
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C.2 Enhanced SUOTA example-use of HTTPS from FP 
to MS, initiated by the MS 

Clause C.2 illustrates one Enhanced SUOTA (see clause 7.6.2.3) use case: use of an enhanced feature (https) initiated 
by the MS. 

Enhanced SUOTA is initiated by the MS in step 2, requiring the use of HTTPS toward the server, after receiving a plain 
http request (FP_URL1 = http://pp-ms.example.com/info?EMC=01ab&SWVid=312E3130&HWVid=322E3237). 

Receiving a request to FP_URL1, the MS requires an upgrade to TLS. As a result, HTTPS is used for the FP to MS 
session, and also for the downloading of files (as in clause C.l). 

NOTE: In this example, although Enhanced SUOTA is used, the MS used is still a Basic SUOTA complying MS 
(using clauses B.l and B.2 but with security features). 

In this example, the URL2 value sent by the FP to the PP is a temporary local URL pointing to the FP itself as described 
in clause 7.6.2.3.3, "Step 3-Enhanced SUOTA possible variants", the FP acting as local server. Alternatively, if the PP 
supports security requirements and the FP knows this, the FP could directly send a "distant" URL2 value with security 
requirements, as in clause C.l). 



£75/ 



93 



ETSI TS 102 527-4 V1.1.1 (2009-10) 



PP 



FACILITY 



FP 



« IWU-to-IWU handset version indication, URL to follow=1 
FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 

URL content part = URL1 = http://pp-ms.example.com/info » 



FP replaces 
real fp-ds uri 
with self- 
pointing 
(temporary) urI 



Downloading 
server 
(pp-ds) 



Management 

server 

(pp-ms) 



r 

HTTP GET to FP_URL1 = 

http://pp-ms.example.com/info? 

EI\/IC=01 ab&SWVid=4649524d5741 5 

2452d31 2e322e30&HWVid=322E32 



HTTP/1.1 426 Upgrade Required 

Upgrade: TLS/1.0, HTTP/1.1 




TLS handshake with FP URL1 



HTTP GET to FP_URL1 (again) 




FACILITY 



« IWU-to-IWU handset version available, software version, 
delay suggestion, URL to follow=1 » 




FACILITY 



« IWU-to-IWU URL indication, URL to follow=0, 

URL content part = URL2 = http://localhost/SUOTA/PP1 reql » 



Use of Binary Content Download (7.6.1) for actual software image download 



includes FP_URL2 = 
https://pp-ds.example.com/img.bin 



TLS connection closed 



Data channel establishment, see clause 7.6.1 .4 



HTTP partial GET to URL2 = http://localhost/SUOTA/PP1req1 pointing to FP. 
GET /SU0TA/PP1 reql HTTP1.1 



Host: localhost 

Accept: application/octet-stream 

Range: bytes=0-99999 



HTTP1 .1 206 Partial Content 



Partial image file 



HTTP partial GET to URL2 = http://localhost/SUOTA/PP1 req1 pointing to FP. 
GET /SU0TA/PP1 reql HTTP1.1 



Host: localhost 

Accept: application/octet-stream 

Range: bytes=1 00000-1 20000 



HTTP1 .1 206 Partial Content 



Partial image file 



Image 

retrieval with 

HTTP-based FP 

authentication -i- 

HTTPS to 

FP URL2 



Image 
( retrieval , 
next part 



Data channel release, see clause 7.6.1 .4 




Figure C.2: Example of Enhanced SUOTA-use of HTTPS from FP to MS, initiated by the MS 
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C.3 Enhanced SUOTA example-use of HTTPS from FP 
to MS, initiated by the FP 

Clause C.3 illustrates one Enhanced SUOTA (see clause 7.6.2.3) use cases: use of an enhanced feature (https) initiated 
by the FP. 

This use case is similar to the one described in clause C.2, because the result is the same: URLl is used, except that 
HTTPS is used instead of HTTP. However the way HTTPS use is initiated is different. 

In the present example, Enhanced SUOTA is initiated by the FP in step 1, directly setting an HTTPS connection with 
the MS to pp-ms.example.com because URLl = http://pp-ms.example.com/info is recognized as a known URLl value 
(e.g. because pp-ms = fp-ms). 

NOTE: In this example again, as in clause C.2, and although Enhanced SUOTA is used, the MS used is still a 
Basic SUOTA complying MS (using annexes B.l and B.2 but with security features). 

In this example again, the URL2 value sent by the FP to the PP is a temporary local URL pointing to the FP itself as 
described in clause 7.6.2.3.3, "Step 3-Enhanced SUOTA possible variants", the FP acting as local server. Alternatively, 
if the PP supports security requirements and the FP knows this, the FP could directly send a "distant" URL2 value with 
security requirements, as in clause C.l). 
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Figure C.3: Example of Enhanced SUOTA-use of HTTPS from FP to MS, initiated by the FP 
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C.4 Enhanced SUOTA example-use of TR-069 [i.5] 
C.4.1 Introduction and diagram 

Clause C.4 illustrates one Enhanced SUOTA (see clause 7.6.2.3) use case: the FP triggers the use of TR-069 [i.5], 
because it knows the MS requires it. 

In the present example, the used MS is TR-069 compliant. The FP is the TR-069 client and knows the MS. It uses this 
MS to manage its own firmware updates, as well as the PPs firmware updates. 

NOTE 1: In the context of TR-069 [i.5], the management server is called the "ACS" (Auto-Configuration Server). 

The FP to MS connection is enciphered using TLS/SSL. The FP (i.e. the TR-069 client) should authenticate to the 
management server using either HTTP basic or digest authentication, or a SSL/TLS based strong authentication. 

The FP still uses the parameters received in the "Handset version indication" message, but posts them in a TR-069 
compliant message to the management server ("Inform" message). 

The TR-069 compliant scenario requires the following adjustments to the four "SUOTA protocol steps" described in 
clauses 7.6.2.2 and 7.6.2.3: 

TR-069 requires the FP (TR-069 client) to notify the MS, for each file, of the correct download and application 
(e.g. installation). The present example interprets the sending of a "Handset version indication" for 
fileNumber="n" by the PP as an acknowledgement of correct download and application of file "n-l". This 
allows the FP to first send a TransferComplete message for file "n-l" in step 2. 

For the sake of clarity, message exchanges between the FP and MS in step 2 are split into two TR-069 
sessions. In a real life case, "TransferComplete" message from FP to MS for file "n-l" and "Download" 
message from MS to FP for file "n" could be exchanged in the same session. 

This example assumes that file url number "n" is received from the MS in the n'^'^ use of step 2 (not in the first 
use of step 2, as it would be the case with Basic SUOTA). This is however not necessarily the case: step 2 
could include several download requests from the MS. For example, the MS could send all download requests 
in the first use of step 2, allowing the FP to get all file urls in one step as for Basic SUOTA. 

NOTE 2: TR-069 allows a device to refuse some download requests, using "9004 Resources exceeded" fault 

message toward the server as described in clause C.4. 2. 3. 3. In that case the MS will repeat this requests 
during the next connections. 
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Figure C.4: Example of Enhanced SUOTA- FP as TR-069 client 
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C.4.2 Detailed messages 
C.4.2.1 General message format 

TR-069 uses a SOAP envelope encompassing each of the exchanged messages. The message itself is inserted as the 
soapenv:Body element content. For conciseness, the following envelope is not repeated in the message descriptions of 
the following clauses. 

<soapenv: Envelope soapenv: encodingStyle="http : //schemas .xmlsoap . org/ soap/ encoding/" 
xmlns : soapenv="http : //schemas .xmlsoap . org/soap/envelope/" 
xmlns : soap="http : //schemas .xmlsoap .org/ soap /encoding/" 
xmlns : xsd= " ht tp : / /www . w3 . org/ 2 01 /XMLSchema " 
xmlns :xsi="http : //www. w3 . org/2 1/XMLSchema- instance" 
xmlns="urn:dslf orum-org: cwmp-1-0" > 

< soapenv: Header > 

<ID soapenv:mustunderstand="i"> <!-- Unique session ID defined by the session initiator--></iD> 
<NoMoreRequests soapenv :mustUnderstand="0" >l</NoMoreRequests> 

</ soapenv: Header > 

< soapenv : Body > 

<\- Message content as described in tlie foiiowing clauses goes here-> 

</ soapenv: Body > 
</soapenv: Envelope> 

The <ID> element content is a unique ID for the TR-069 session, chosen by the session initiator, and inserted by both 
sides (FP and management server) in every message pertaining to this session. Thanks to this ID the other side is able to 
uniquely identify the session to which a received message belongs. 

C.4.2. 2 Preliminary "Inform" exchange 
C.4.2.2.1 Inform 

Assumption is made here that the same session (hence the same "Inform" message) is used for both: 

the FP acknowledging a previous successful or failed "Download", using a "TransferComplete message. This 
accounts for the presence of an event of type "7 TRANSFER COMPLETE" in the Inform message <Event> 
element. The command key value for this event should be copied from the corresponding Download message. 

the MS requesting a download by the device (represented by the FP), using a "Download" message. This 
accounts for the presence of an event of type "2 PERIODIC" in the Inform message. The command key value 
for this event should remain empty. 



ETSI 



99 ETSI TS 102 527-4 V1.1.1 (2009-10) 

<Inf orm> 

<Deviceid> <\--FP identification-> 

<Manufacturer>SUPPLIERXY< /Manufacturer > 
<oui >xxxxxx< /oui > <\-- Organizationally Unique ldentifier-> 
< Product Class>ProductZ</ProductClass> 
<SerialNumber>SN-XYZT</SerialNumber> 
</DeviceId> 

<Event soap : arrayType="cwmp : EventStruct [2] "> 
< Event St rue t> 

<EventCode>2 PERIODIC</EventCode> 
<CommandKey> <!-- Must remain empty --></CommandKey> 
</ Event St rue t> 
<Eventstruct> <!-- This event indicates that the transferComplete method will be tried later in the session -> 

<EventCode>7 TRANSFER COMPLETE</EventCode> 

<commandKey> <!-- command l<ey copied from corresponding Download message --></commandKey> 
</ Event St rue t> 
</ Event > 

<MaxEnvelopes>l</MaxEnvelopes> 

<CurrentTime>2008-09-15T15 :40 : OOZ</CurrentTime> 
< Re t ry Count > < / Re t ry Count > <\- Starts at 0-> 

< Parameter Li St soap : arrayType="cwmp : ParameterValueStruct [5] "> 
<ParameterValueStruct> 

<Name>Device . Devi ceSummary< /Name > 
< Value xsi : type="xsd: string" ></Value> 
</ParameterValueStruct> 
<ParameterValueStruct> 

<Name>Device .Deviceinf o.HardwareVersion</Name> 
< Value xsi : type="xsd: string" ></Value> 
</ParameterValueStruct> 
<ParameterValueStruct> 

<Name>Device .Deviceinf o. Sof twareVersion</Name> 
< Value xsi : type="xsd: string" ></Value> 
</ParameterValueStruct> 
<ParameterValueStruct> 

<Name>Device . Management Server . ConnectionRequestURL</Name> 
< Value xsi : type="xsd: string" ></Value> 
</ParameterValueStruct> 
<ParameterValueStruct> 

<Name>Device . Management Server . ParameterKey</Name> 
< Value xsi : type="xsd: string" ></Value> 
</ParameterValueStruct> 
<ParameterValueStruct> 

<Name>Device . LAN . IPAddress</Name> 
< Value xsi : type="xsd: string" >< /Value > 
</ParameterValueStruct> 
</ParameterList> 
</lnf orm> 

NOTE: In this example, the value "2 PERIODIC" is used by the FP, indicating that the "Inform" request belongs 
to a set of periodically sent "Inform" messages. This is because the Inform message is supposed to be sent 
following a periodically sent "Handset Version Indication" command. 

C.4.2.2.2 Inform Response 

InformResponse from the management server acknowledges receipt of the Inform message. 

<Inf ormResponse> 

<MaxEnvelopes>l</MaxEnvelopes> 
</Inf ormResponse> 

C.4.2.3 Download exchange 
C.4.2.3.1 Download (from server to FP) 

The Download message is the request from the management server that will cause the FP to download one file. 
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The time at which the download takes place is described in the message with a delay in seconds from the time when the 
message was received. In the corresponding "Handset version indication" command, the FP should therefore use a value 
of <DelayMinutes> = (DelaySeconds/60) minutes. 

NOTE: The sequencing of actual file downloads with TR-069 is therefore time-based. 

<Download> 

<CommandKey>< ! --server defined download instance ref . --></CommandKey> 

<FileType>l Firmware Upgrade Image</Event> 

<URL> <!-- download target url = FP_URL2 --> </URL> 

<Username> <!-- if authentication needed --> </Username> 

<Password> <!-- if authentication needed --> </Password> 

<FileSize> <!-- file size in bytes --> </FileSize> 

<TargetFileName> <!-- in FP or PP file system --> </TargetFileName> 

<DelaySeconds> <!-- DelayMinutes = DelaySeconds/60 --> </DelaySeconds> 

<SuccessURL> <!-- optional , for browser --> </SuccessURL> 

<FailureURL> <!-- optional , for browser --> </FailureURL> 
</Download> 

C.4.2.3.2 DownloadResponse (from FP to server) 

DownloadResponse is used in case of successful "Download" request. The FP should always set the status to "1", 
indicating that the download result will be notified in a subsequent TransferComplete message (i.e. the download will 
not take place immediately). 

<DownloadResponse> 

<Status> 1 </Status> 
</DownloadResponse> 

Error handling. In the following cases, the FP should answer the "Download" request with a fault message as defined 
in clause B.4.2.3: 

9004 Resources exceeded: if an attempt is made to queue an additional "Download" request when the FP's 
file transfer queue is already full. 

9003 Invalid arguments: should be used to reject the Download request if the FP detects the presence of the 
"userinfo" component in the file source URL. 

9010 Download Failure: if the FP rejects the Download request because the FileSize argument exceeds the 
available space on the device. 

9012 File transfer server authentication failure (associated with Upload, Download, TransferComplete or 
AutonomousTransferComplete methods). 

9013 Unsupported protocol for file transfer (associated with Upload and Download methods). 
NOTE: The above list does not mention the all-purpose error codes described in clause B.4.2.3. 

C.4.2.3.3 Preventing too many Download messages 

The management server could attempt to send several "Download" requests in a row (i.e. not sending HTTP response 
204 immediately). In case the FP wishes to handle a limited number of "Download" requests at a time, it may reply with 
a "9004 Resources exceeded" SOAP error message (see clause B.4.2.3). 

NOTE 1: However, a FP using TR-069 should be able to queue at least three file transfers (download or upload). 

NOTE 2: Whatever strategy is used on FP side, each file download will only start following a PP originating 
"Handset Version indication" message to the FP. 
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Figure C.5: Prevent multiple Download requests from the management server 

C.4.2.4 Transfer complete exchange 

For each download performed, the FP will send a distinct TransferComplete message to the management server. This 
message should only be sent upon successful download and use (e.g. installation, test) of the file. If the download and/or 
use of the file fails, the device should not retry the download but will use the TransferComplete message to report a 
failure to the management server. 

C.4.2.4. 1 TransferComplete (from FP to server) 

The command key value should again be copied from the corresponding Download message (as for the Inform 

message). 

<Transf erComplete> 

<CommandKey> <<.--server defined download instance ref.--> </CommandKey> 
<FaultStruct> 

< Paul t Codex /Fault Code > 

< Paul t St ringx/ Fault St ring> 
</FaultStruct> 
<StartTime> </StartTime> 
<CompleteTime> </CompleteTime> 

</Transf erComplete> 

C.4.2.4. 2 TransferCompleteResponse (from server to FP) 

TransferCompleteResponse is an empty response message acknowledging receipt of the TransferComplete message. 

<Transf erCompleteResponse/> 

C.4.2.5 Error handling-"Fault" message 

In order to notify an error to the other party, the FP or management server should send a "Fault" message of the 
following form. 

NOTE 1 : A Fault message is sent on the SOAP layer. 
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<soap: Envelope 

xmlns : soap="http : // schema s .xmlsoap . org/ soap /envelope/ " 
xmlns : cwmp= "urn : dslf orum-org : cwmp- 1- 1 " > 

<soap :Header> 

<cwmp : ID soap :mustUnderstand="l">1234</cwmp : ID> 
</soap : Header> 

<soap :Body> 

<soap : Fault > 

<f aultcode>Server</f aultcode> 

<f aultstring>CWMP f ault< /fault string > 

<detail> 

<cwmp : Fault> 

<FaultCode>90 0</FaultCode> 

<FaultString>Download method not supported</FaultString> 
</cwmp : Fault > 
</detail> 
</soap : Fault> 
</soap :Body> 

</soap : Envelope> 

NOTE 2: FP to management server error codes are of the form 9xxx. Management server to FP errors are of the 
form 8xxx. 

All purpose error codes are defined in the following table: 

Table C.I : Error codes 



Management server to FP response 
(SOAP faultcode value = "Server") 


FP to management server response 
(SOAP faultcode value = "Server") 


Description 


8000 


9000 


Method not supported 


8001 


9001 


Request denied (no reason specified) 


8002 


9002 


Internal error 



C.4.2.6 Alternative exchanges 

C.4.2.6.1 RequestDownload (from server to FP) 

In some cases, the FP could use the RequestDownload message, in order to force a "Download". 

NOTE 1 : A management server could not implement this method. 

NOTE 2: The FP cannot require a specific "Download" message instance. 

<RequestDownload> 

<FileType>l Firmware Upgrade Image</Event> 
</RequestDownload> 
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Figure C.6: Use of the RequestDownload method 

C.4.2.6.2 RequestDownloadResponse (from server to FP) 

RequestDownloadResponse is an empty response message acknowledging receipt of the RequestDownload message. 

<RequestDownloadResponse/ > 

Error handling: In the following cases, the management server will answer the RequestDownload request with a fault 
message as defined in clause B.4.2.3, instead of a RequestDownloadResponse message. The applicable codes are the 
following: 

Error code Error string SOAP faultcode 

8003 Invalid arguments Client 

8005 Retry request Server 

NOTE: The above list of applicable codes does not mention the all-purpose error codes described in clause B.4.2.3. 
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